jiebi/CodeConvo huggingface dataset:
Change:
// even if their `ObligationCauseCode` isn't an `Expr*Obligation` kind. // This is important since if we adjust one span but not the other, then // we will have "duplicated" the error on the UI side. <del> let mut remap_cause = FxHashSet::default(); </del> <ins> let mut remap_cause = FxIndexSet::default(); </ins> let mut not_adjusted = vec![]; for error in errors {

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: Diesel has a larger amount of compile test to check whether some constructs are rejected at compile time and to check for specific error messages. These tests are implemented using trybuild. We pin specific compiler versions as the output obviously might change with newer compiler versions. From time to time an update of the pinned version is required. While doing such an update we noticed that newer versions of rustc do emit non-deterministic error messages. These sometimes include more or less information. To reproduce this behaviour perform the following steps: We do not observe this behaviour with . I've observed this behaviour at least since (that's the earliest nightly I've checked, so there might be earlier versions as well) Exemplary changes between two runs (obviously that changes as well): <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If you have time, it would be helpful to find exactly which commit regressed this (using ).
searched nightlies: from nightly-2022-08-12 to nightly-2022-09-15 regressed nightly: nightly-2022-08-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: : </detailscc as author of the relevant PR
I'll take a look. claim
Change:
/// Generates an appropriate parsing failure message. For EOF, this is "unexpected end...". For /// other tokens, this is "unexpected token...". <del> pub(super) fn parse_failure_msg(tok: &Token) -> Cow<'static, str> { match tok.kind { token::Eof => Cow::from("unexpected end of macro invocation"), _ => Cow::from(format!("no rules expected the token `{}`", pprust::token_to_string(tok))), </del> <ins> pub(super) fn parse_failure_msg(tok: &Token, expected_token: Option<&Token>) -> Cow<'static, str> { if let Some(expected_token) = expected_token { Cow::from(format!( "expected `{}`, found `{}`", pprust::token_to_string(expected_token), pprust::token_to_string(tok), )) } else { match tok.kind { token::Eof => Cow::from("unexpected end of macro invocation"), _ => { Cow::from(format!("no rules expected the token `{}`", pprust::token_to_string(tok))) } } </ins> } }

Discussion:
one of the desired output should be much help, rather than: No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // ignore-tidy-linelength fn main() { let unicode_is_fun = "؁‱ஹ௸௵꧄.ဪ꧅⸻𒈙𒐫﷽𒌄𒈟𒍼𒁎𒀱𒌧𒅃 𒈓𒍙𒊎𒄡𒅌𒁏𒀰𒐪𒐩𒈙𒐫𪚥"; let _ = "ༀ༁༂༃༄༅༆༇༈༉༊་༌།༎༏༐༑༒༓༔༕༖༗༘༙༚༛༜༝༞༟༠༡༢༣༤༥༦༧༨༩༪༫༬༭༮༯༰༱༲༳༴༵༶༷༸༹༺༻༼༽༾༿ཀཁགགྷངཅཆཇ཈ཉཊཋཌཌྷཎཏཐདདྷནཔཕབབྷམཙཚཛཛྷཝཞཟའཡརལཤཥསཧཨཀྵཪཫཬ཭཮཯཰ཱཱཱིིུུྲྀཷླྀཹེཻོཽཾཿ྄ཱྀྀྂྃ྅྆྇ྈྉྊྋྌྍྎྏྐྑྒྒྷྔྕྖྗ྘ྙྚྛྜྜྷྞྟྠྡྡྷྣྤྥྦྦྷྨྩྪྫྫྷྭྮྯྰྱྲླྴྵྶྷྸྐྵྺྻྼ྽྾྿࿀࿁࿂࿃࿄࿅࿆࿇࿈࿉࿊࿋࿌࿍࿎࿏࿐࿑࿒࿓࿔࿕࿖࿗࿘࿙࿚"; let _a = unicode_is_fun + " really fun!"; //~^ ERROR binary operation `+` cannot be applied to type `&str` } </ins>

Discussion:
In we account for the visible char width when calculating the label and span positions, but we do not do so for the vertical bar tying them together, causing the following output: where it should be (Found during )
I would like to solve this as a first time issue. Best with some pointers where to start :)
the code that draws the vertical lines is at and the one that draws the span labels is right below I think the error might be using instead of , but I'm not entirely certain. If this is your first time compiling , you probably want to read the , but the TL;DR: is "run to build the compiler up to the first stage and update the test output files". You might also want to wait until the linked PR is merged so you have a test case, unless you wish to come up with a new one (look for a test that has multiple labels in the same span and pad the source to the left with unicode chars on non-1 width).
Thank you! I did read the rustc guide, and even compiled it on my own once. But thanks for the direction, and the note to the PR. I'll do my best :wink:
Change:
"core 0.0.0", "dlmalloc 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", "fortanix-sgx-abi 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)", <del> "hashbrown 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "hashbrown 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "libc 0.2.54 (registry+https://github.com/rust-lang/crates.io-index)", "panic_abort 0.0.0", "panic_unwind 0.0.0",

Discussion:
In 1.35, 's requires , but in 1.36-beta it requires . Both are auto-derived, so it must be a change in their internals. Obviously, is quite different than the old implementation. ! ! Ditto for . I'm not sure if there's any real impact in this, but it should be considered, and perhaps audit for other similar changes. cc as discussed on IRC.
This is fixed in hashbrown 0.4.0.
Shouldn't be fixed as well?
Since is actually based on , it derives the same constraints.
Ah, gotcha. Thanks! Sorry for the false alarm :).
I think it would be a good idea to add a run-pass to check that these auto-trait impls don't change again.
might make sense to add them as tests to most collections. , , etc. don't have tests for these either. I've made this error in some of my collections (changing some internal implementation detail and breaking users that rely on auto traits working "like before").
Change:
<ins> // Issue #122508 //@ check-pass //@ incremental //@ edition:2021 trait MyTrait { async fn bar(&self) -> i32; } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [associatedtypeforimpltraitintrait] creating the associated item corresponding to the opaque type [associatedtypesforimpltraitsinassociatedfn] creating associated items for opaque types returned by [associateditemdefids] collecting associated items or fields of [associateditems] collecting associated items of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
This will probably make a simple crash in a lot of cases :3
cc
minimal repro:
Hmm, when writing I tried to trigger the case by enabling , but it didn't ICE. I'll check what is the difference with what cargo does.
Fixed in
A workaround to this issue should be to use or which should disable incremental compilation.
run on nightly rust also  but. if you use to switch stable version rust will be run will successful
There’s also an environment variable to control incremental compilation, so you could set CARGO_INCREMENTAL=0 to do that.
I think this error should be completely fixed, otherwise it will still fail to compile in the IDE environment and the automatic build environment of GitHub Action
Sure, we were just offering a workaround to unblock people temporarily. The fix is already present on master and should be available in tomorrow’s nightly.
Oh, this is great
Change:
#[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> impl Writer for @Writer { fn write(&self, v: &[const u8]) { self.write(v) } fn seek(&self, a: int, b: SeekStyle) { self.seek(a, b) }

Discussion:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.
Change:
build.rust_root = os.path.abspath(os.path.join(__file__, '../../..')) build.verbose = args.verbose != 0 build.clean = args.clean <ins> build.json_output = args.json_output </ins> # Read from `--config`, then `RUST_BOOTSTRAP_CONFIG`, then `./config.toml`, # then `config.toml` in the root directory.

Discussion:
I think this is one of the reasons (maybe not the only one?) that introducing a build failure in src/bootstrap means that rust-analyzer doesn't show red squigglies in the IDE. Mentoring instructions: add a new flag to around and pass to cargo around if it's set. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc https://rust-
claim
Solving this may also solve
Change:
struct_span_err!(tcx.sess, span, E0733, "recursion in an `async fn` requires boxing") .span_label(span, "recursive `async fn`") .note("a recursive `async fn` must be rewritten to return a boxed `dyn Future`") <ins> .note( "consider using the `async_recursion` crate: https://crates.io/crates/async_recursion", ) </ins> .emit(); }

Discussion:
We should suggest the use of when writing :
Is there any precedent for the compiler suggesting an external crate?
Yes, for async traits the compiler suggests to use :
As pointed out, we do for . We normally wouldn't recommend one crate over another ("don't play favorites"), but for small, single use, specialized crates that fill a common language "hole" that we might be working towards "plugging", I think it is a much better experience to immediately unblock newcomers than send them to a user forum to ask how to get around the limitation. The current error gives some idea of how to fix this, but not nearly enough for an even moderately knowledgeable Rust user to fix the problem without some searching. That being said, thanks for double checking and mildly pushing back on a potentially controversial and "uncommon" request. That is important for the health of the project.
Change:
use test_result::*; use time::TestExecTime; <del> use options::{RunStrategy, Concurrent, RunIgnored, ColorConfig}; </del> <ins> use options::{RunStrategy, Concurrent}; </ins> use event::{CompletedTest, TestEvent}; <del> use cli::TestOpts; </del> use helpers::sink::Sink; use helpers::concurrency::get_concurrency; use helpers::exit_code::get_exit_code;

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
fn deref<'a>(&'a self) -> &'a Result; } <ins> #[cfg(not(stage0))] impl<'a, Sized? T> Deref<T> for &'a T { fn deref(&self) -> &T { *self } } #[cfg(not(stage0))] impl<'a, Sized? T> Deref<T> for &'a mut T { fn deref(&self) -> &T { *self } } </ins> /** * * The `DerefMut` trait is used to specify the functionality of dereferencing

Discussion:
As titled. Add the following trait implementations: This allows generic code that accepts smart pointer can take references too, e.g.
cc
yes I want this :+1:
This would also allow code to be polymorphic over &T and &mut T by accepting . A huge win imho.
The branch creates some .
Change:
<ins> # `char_error_internals` This feature is internal to the Rust compiler and is not intended for general use. ------------------------ </ins>

Discussion:
I'm not sure if this is an oversight. But the implementation should be trivial. I'll add tests and implement it, if it is fine.
Strings aren't indexable and .len() doesn't count the number of chars. :smile: What comes to mind first is an iterator inspecting the two first chars:
xD I didn't test my code, but you get the gist. I had a impl at first, but then edited it
cc
Triage: this has not been .
PRs welcome!
I can take this. I was also thinking of adding a impl for , but unsure if it would be better to wait for to get closer to stabilization and use that instead of adding another empty enum to std
wait, that wouldn't work bc of lifetime issues regardless, right? :(
Change:
<ins> fn main() { let x = -1 as usize; //~ ERROR: cannot apply unary operator `-` let x = (-1) as usize; //~ ERROR: cannot apply unary operator `-` let x: u32 = -1; //~ ERROR: cannot apply unary operator `-` } </ins>

Discussion:
Code: Playground: Error message: Somehow, in one case this in the expression is unsigned, but in the other case it is signed and everything is fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
For the compiler has to suggest to replace it with . The compiler should also suggest to replace with , to remove some hard "as" casts from the code.
claim
I think this is more appropriate as a clippy lint, opened
Change:
#[stable(feature = "rust1", since = "1.0.0")] impl fmt::Debug for CString { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> fmt::Debug::fmt(&String::from_utf8_lossy(self.as_bytes()), f) </del> <ins> fmt::Debug::fmt(&**self, f) } } #[stable(feature = "cstr_debug", since = "1.3.0")] impl fmt::Debug for CStr { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { try!(write!(f, """)); for byte in self.to_bytes().iter().flat_map(|&b| ascii::escape_default(b)) { try!(f.write_char(byte as char)); } write!(f, """) </ins> } }

Discussion:
CString should escape its contents like a byte string, not trying to show it as utf-8. Right now it does the latter via
For example, if the CString contains the byte , I would expect that to be visible in the Debug output.
Change:
//~| ERROR `...` range patterns are deprecated //~| ERROR mismatched types } <ins> fn with_macro_expr_var() { macro_rules! mac2 { ($e1:expr, $e2:expr) => { let $e1..$e2; let $e1...$e2; //~^ ERROR `...` range patterns are deprecated let $e1..=$e2; } } mac2!(0, 1); macro_rules! mac { ($e:expr) => { let ..$e; //~ ERROR `..X` range patterns are not supported let ...$e; //~ ERROR `...X` range patterns are not supported //~^ ERROR `...` range patterns are deprecated let ..=$e; //~ ERROR `..=X` range patterns are not supported let $e..; //~ ERROR `X..` range patterns are not supported let $e...; //~ ERROR `X...` range patterns are not supported //~^ ERROR `...` range patterns are deprecated let $e..=; //~ ERROR `X..=` range patterns are not supported } } mac!(0); } </ins>

Discussion:
The CI for started to fail today with this error: It appears as though the compiler doesn't see and only sees as the range expression and then generates this error. The expression is inside a expansion. You can reproduce this by cloning the repo and building it: The build succeeds on the stable channel and much older releases, so this appears to be a regression in the nightly. Here's the version on my windows system, but note that this also fails on linux and macos too:
Regression introduced in
More specifically the bug is in: which is called to see whether what follows is a valid start of a range pattern end expression. This is strange tho... in the case of e.g.: the call to in is used successfully to parse but somehow that doesn't work for . cc
Similarly, with: this does not trigger "error: range patterns are not supported" but it should.
Change:
<del> Subproject commit fc96aa036884183ddc68d2659f4633e6f138b4e0 </del> <ins> Subproject commit 341c96afd331195beeb001436535c1feb479ff9d </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.

Assertion failed: ((NumParams == FTy-getNumParams() (FTy-isVarArg() && NumParams FTy-getNumParams())) && "Calling a function with bad signature!"), function init, file , line 187.
Should be rejected by the typechecker.
Change:
* '', or, equivalently, '.' (understood as 0) * '5.' * '.5', or, equivalently,  '0.5' <ins> * 'inf', '-inf', 'NaN' </ins> Leading and trailing whitespace are ignored.

Discussion:
Should float::fromstr do the following conversions? "NaN" -float::NaN "inf" -float::infinity "-inf" -float::neginfinity That'd match what float::to_str does (if my pull request is merged.) If this sounds good I'll chuck a patch in.
It will be very good when this will be fixed. There are some additional points to be considered: If I remember correctly, the floating point standard allows for both short ("inf") and long ("infinity") syntax. Are you aware of the other float formatting related issues? I think there used to be a floating point literal parsing problem in rustc for very large literals (not fitting into 32 bits) that is related (can't find the issue right now). Besides adding support for NaN and inf in fromstr/tostr, I personally think rust should define a literal syntax for these, i.e. the compiler should support them directly.
If this is standard behavior for converting from strings than I say go for it.
More things to check proper handling of +0.0 vs -0.0 vs 0.0 hexadecimal notation for the mantissa for the lossless exchange of values
The last one is discusses in . The real kicker would be if all this were supposed by the parser as literal syntax.
Fixed by
Change:
debug!(" => associated item with unsizeable self: Self"); Some(Instance { def: InstanceDef::VtableShim(def_id), substs }) } else { <del> Instance::resolve(tcx, param_env, def_id, substs).ok().flatten() </del> <ins> Instance::resolve_for_fn_ptr(tcx, param_env, def_id, substs) </ins> } }

Discussion:
After reducing a from I get a segfault from : This repros for me on my up-to-date checkout as well as for the current beta compiler. I'm not sure whether that makes this a regression from stable to beta, since it's an apparent bug in an API which is first stabilizing in this release. cc
this causes a segfault on stable: results in Luckily is very rarely used
Oof! I'm looking at the existing tests and I realize what we missed. We test direct calls to tracked trait methods and we test indirect calls to tracked trait functions (i.e. no receivers), but we don't test indirect calls of trait methods with receivers.
My immediate suspicion is that trait object vtables aren't going through the reification path we to .
Thanks to for confirming this .
Opened with a fix, thanks again to for help finding the missing call!
Assigning .
Change:
<ins> error[E0308]: mismatched types --> $DIR/return-closures.rs:3:5 | LL | fn foo() { |          - help: try adding a return type: `-> impl for<'r> Fn(&'r i32) -> i32` LL | LL |     |x: &i32| 1i32 |     ^^^^^^^^^^^^^^ expected `()`, found closure | = note: expected unit type `()` found closure `[closure@$DIR/return-closures.rs:3:5: 3:14]` error[E0308]: mismatched types --> $DIR/return-closures.rs:9:5 | LL | fn bar(i: impl Sized) { |                       - help: a return type might be missing here: `-> _` LL | LL |     || i |     ^^^^ expected `()`, found closure | = note: expected unit type `()` found closure `[closure@$DIR/return-closures.rs:9:5: 9:7]` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest how to specify the return type when a function returns a closure. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Is some thing like this not ok ?
release-assignment
It's ok but I was wondering if it's possible to make the compiler give some form of a suggestion to the user on how to do this. Cause the current diagnostics does not suggest how to fix it.
Change:
<del> // edition:2018 // Tests that `meta` is allowed, even if the crate doesn't exist // yet (i.e., it causes a different error than `not-allowed.rs`). use meta; //~ ERROR can't find crate for `meta` fn main() {} </del>

Discussion:
Taken from this internals thread: A module named is shadowed leading to misleading error messages. was reserved as a built-in crate name in 2018 edition, but the error message does not indicate this. I tried this code: Above code compiled with This is expected to indicated that is a reserved crate name. Instead, the following error is reported: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Error: Parsing assign command in failed: ...'tbot claim' ' ?'... Please let know if you're having trouble with this bot.
claim
It's not forbidden as a module name, this obviously works: I think the confusion arises from that fact that this works without : But those are uniform imports (or at least I think that's what they're called), and only resolve to the surrounding scope if unambiguous (which it is for due to the. I'm guessing the right fix here is to add more information to the error suggesting that if the intention wasn't to refer to a crate, or etc. should/can be used explicitly. (EDIT: I went to the internals thread to reply, and it's from March 2019 apparently, and also was mentioned there, but I guess the fact that the name is perfectly fine outside of wasn't brought up) cc
I believe the "fix" was mentioned in a reddit thread linking to the internals thread, but I forgot to mention it. I will reword the issue as it is misworded, as you pointed out. Lastly, what you suggested for a fix lines up with what I was expecting. Also, now you know how deep my backlog of todo items is.