jiebi/CodeConvo huggingface dataset:
Code change:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

Related discussion:
text: <ins> error[E0594]: cannot assign to `*input` which is behind a `&` reference --> $DIR/issue-68049-2.rs:9:7 | LL |   fn example(&self, input: &i32); // should suggest here |                            ---- help: consider changing that to be a mutable reference: `&mut i32` ... LL |       *input = self.0; |       ^^^^^^^^^^^^^^^ `input` is a `&` reference, so the data it refers to cannot be written error[E0594]: cannot assign to `self.0` which is behind a `&` reference --> $DIR/issue-68049-2.rs:17:5 | LL |   fn example(&self, input: &i32); // should suggest here |              ----- help: consider changing that to be a mutable reference: `&mut self` ... LL |     self.0 += *input; |     ^^^^^^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be written error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0594`. </ins>
Code change:
The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in

Related discussion:
text: self.sess.gated_spans.gate(sym::const_extern_fn, lo.to(self.token.span)); } let ext = self.parse_extern()?; <del> self.bump(); // `fn` </del> <ins> self.expect_keyword(kw::Fn)?; </ins> let header = FnHeader { unsafety,
Code change:
The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in

Related discussion:
text: <ins> fn main() {} #[cfg(FALSE)] fn container() { const unsafe WhereIsFerris Now() {} //~^ ERROR expected one of `extern` or `fn` } </ins>
Code change:
The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in

Related discussion:
text: <ins> error: expected one of `extern` or `fn`, found `WhereIsFerris` --> $DIR/issue-68062-const-extern-fns-dont-need-fn-specifier-2.rs:5:18 | LL |     const unsafe WhereIsFerris Now() {} |                  ^^^^^^^^^^^^^ expected one of `extern` or `fn` error: aborting due to previous error </ins>
Code change:
The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in

Related discussion:
text: <ins> fn main() {} #[cfg(FALSE)] fn container() { const extern "Rust" PUT_ANYTHING_YOU_WANT_HERE bug() -> usize { 1 } //~^ ERROR expected `fn` //~| ERROR `const extern fn` definitions are unstable } </ins>
Code change:
The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in

Related discussion:
text: <ins> error: expected `fn`, found `PUT_ANYTHING_YOU_WANT_HERE` --> $DIR/issue-68062-const-extern-fns-dont-need-fn-specifier.rs:5:25 | LL |     const extern "Rust" PUT_ANYTHING_YOU_WANT_HERE bug() -> usize { 1 } |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `fn` error[E0658]: `const extern fn` definitions are unstable --> $DIR/issue-68062-const-extern-fns-dont-need-fn-specifier.rs:5:5 | LL |     const extern "Rust" PUT_ANYTHING_YOU_WANT_HERE bug() -> usize { 1 } |     ^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/64926 = help: add `#![feature(const_extern_fn)]` to the crate attributes to enable error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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.
has landed, so a fix should be possible now. are you on this or should I try my luck?
T-compiler triage: P-medium, removing nomination tag.

Related discussion:
text: <del> Subproject commit 4e44aa010c4c7d616182a3078cafb39da6f6c0a2 </del> <ins> Subproject commit 6a0f14bef7784e57a57a996cae3f94dbd2490e7a </ins>
Code change:
Incorrect hint for variable with a similar name defined using raw identifiers () Errors: Should be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I've fixed this issue and will try to find and fix more similarly incorrect suggestions before submitting a PR.
claim I would love to take this up. It would help to know where I should begin.
Sorry for dropping this, my exams are around the corner.
claim
Hi I'm in the middle of the implementation of this issue. Would it be possible to assign it back to me?
claim
Unfortunately, I'm extremely busy right now, therefore I will unassign me so that someone else can work on it.

Related discussion:
text: let post = format!(", consider renaming `{}` into `{snippet}`", suggestion.candidate); (span, snippet, post) } else { <del> (span, suggestion.candidate.to_string(), String::new()) </del> <ins> (span, suggestion.candidate.to_ident_string(), String::new()) </ins> }; let msg = match suggestion.target { SuggestionTarget::SimilarlyNamed => format!(
Code change:
Incorrect hint for variable with a similar name defined using raw identifiers () Errors: Should be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I've fixed this issue and will try to find and fix more similarly incorrect suggestions before submitting a PR.
claim I would love to take this up. It would help to know where I should begin.
Sorry for dropping this, my exams are around the corner.
claim
Hi I'm in the middle of the implementation of this issue. Would it be possible to assign it back to me?
claim
Unfortunately, I'm extremely busy right now, therefore I will unassign me so that someone else can work on it.

Related discussion:
text: <ins> fn r#fn() {} fn main() { let r#final = 1; // Should correctly suggest variable defined using raw identifier. fina; //~ ERROR cannot find value // Should correctly suggest function defined using raw identifier. f(); //~ ERROR cannot find function } </ins>
Code change:
Incorrect hint for variable with a similar name defined using raw identifiers () Errors: Should be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I've fixed this issue and will try to find and fix more similarly incorrect suggestions before submitting a PR.
claim I would love to take this up. It would help to know where I should begin.
Sorry for dropping this, my exams are around the corner.
claim
Hi I'm in the middle of the implementation of this issue. Would it be possible to assign it back to me?
claim
Unfortunately, I'm extremely busy right now, therefore I will unassign me so that someone else can work on it.

Related discussion:
text: <ins> error[E0425]: cannot find value `fina` in this scope --> $DIR/suggestion-raw-68962.rs:7:5 | LL |     fina; |     ^^^^ help: a local variable with a similar name exists: `r#final` error[E0425]: cannot find function `f` in this scope --> $DIR/suggestion-raw-68962.rs:10:5 | LL | fn r#fn() {} | --------- similarly named function `r#fn` defined here ... LL |     f(); |     ^ help: a function with a similar name exists: `r#fn` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </ins>
Code change:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.

Related discussion:
text: # Use LLVM libunwind as the implementation for Rust's unwinder. # Accepted values are 'in-tree' (formerly true), 'system' or 'no' (formerly false). <ins> # This option only applies for Linux and Fuchsia targets. # On Linux target, if crt-static is not enabled, 'no' means dynamic link to # `libgcc_s.so`, 'in-tree' means static link to the in-tree build of llvm libunwind # and 'system' means dynamic link to `libunwind.so`. If crt-static is enabled, # the behavior is depend on the libc. On musl target, 'no' and 'in-tree' both # means static link to the in-tree build of llvm libunwind, and 'system' means # static link to `libunwind.a` provided by system. Due to the limitation of glibc, # it must link to `libgcc_eh.a` to get a working output, and this option have no effect. </ins> #llvm-libunwind = 'no' # Enable Windows Control Flow Guard checks in the standard library.
Code change:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.

Related discussion:
text: cc = "1.0.67" [features] <ins> # Only applies for Linux and Fuchsia targets # Static link to the in-tree build of llvm libunwind </ins> llvm-libunwind = [] <ins> # Only applies for Linux and Fuchsia targets # If crt-static is enabled, static link to `libunwind.a` provided by system # If crt-static is disabled, dynamic link to `libunwind.so` provided by system </ins> system-llvm-libunwind = []
Code change:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.

Related discussion:
text: println!("cargo:rerun-if-changed=build.rs"); let target = env::var("TARGET").expect("TARGET was not set"); <del> if cfg!(feature = "system-llvm-libunwind") { </del> <ins> if cfg!(target_os = "linux") && cfg!(feature = "system-llvm-libunwind") { // linking for Linux is handled in lib.rs </ins> return; }
Code change:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.

Related discussion:
text: } #[cfg(target_env = "musl")] <del> #[link(name = "unwind", kind = "static", cfg(target_feature = "crt-static"))] #[link(name = "gcc_s", cfg(not(target_feature = "crt-static")))] extern "C" {} </del> <ins> cfg_if::cfg_if! { if #[cfg(all(feature = "llvm-libunwind", feature = "system-llvm-libunwind"))] { compile_error!("`llvm-libunwind` and `system-llvm-libunwind` cannot be enabled at the same time"); } else if #[cfg(feature = "llvm-libunwind")] { #[link(name = "unwind", kind = "static")] extern "C" {} } else if #[cfg(feature = "system-llvm-libunwind")] { #[link(name = "unwind", kind = "static-nobundle", cfg(target_feature = "crt-static"))] #[link(name = "unwind", cfg(not(target_feature = "crt-static")))] extern "C" {} } else { #[link(name = "unwind", kind = "static", cfg(target_feature = "crt-static"))] #[link(name = "gcc_s", cfg(not(target_feature = "crt-static")))] extern "C" {} } } </ins> // When building with crt-static, we get `gcc_eh` from the `libc` crate, since // glibc needs it, and needs it listed later on the linker command line. We
Code change:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.

Related discussion:
text: extern "C" {} #[cfg(all(target_vendor = "fortanix", target_env = "sgx"))] <del> #[link(name = "unwind", kind = "static-nobundle")] </del> <ins> #[link(name = "unwind", kind = "static")] </ins> extern "C" {}
Code change:
The page currently talks only about the use of move with closures. The keyword is also valid before an async block. For example: . This page could be updated to include that usage. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Edit  and make the text talk about async blocks as well.
claim

Related discussion:
text: /// // x is no longer available /// ``` /// <ins> /// `move` is also valid before an async block. /// /// ```rust /// let capture = "hello"; /// let block = async move { ///     println!("rust says {} from async block", capture); /// }; /// ``` /// </ins> /// For more information on the `move` keyword, see the [closure]'s section /// of the Rust book or the [threads] section ///
Code change:
Summary from : used as a tuple-struct constructor function should use the fully type-substituted form from the block, but does not. Thus, today this code is accepted, but it should not be. (Fixing this would be a breaking-change, so we should take care in how we deploy it.) Original bug report follows: <!-- 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. --I tried this code: In nightly rustc, compiles while yields a type mismatch error:
The one is incorrect, has all its generic parameters substituted, i.e. it's / in both cases, type or constructor function.
To be 100% clear here: I believe what is saying is that the compiler has a bug, and that the bug is that the code should be treated as a short-hand for: and thus should be yielding the same error that one sees for the cases in the code from the description. However, the code is not yielding an error at all.
T-compiler triage: leaving nominated for T-lang. Tagging as P-high priority to resolve whether the semantics described by is indeed what we want, and if so, how to address deploying a breaking-change to fix it.
cc I thought we had fixed this bug in (and to be clear, it's clearly a bug (as noted by in ). It should not compile.
Just to simplify a bit (still passes but shouldn't):
Just checked on godbolt and it seems to compile in every stable release since it was stabilized (). I haven't looked into the code again, but I don't really understand how didn't cover this. Did we forget to add a test with errors, and only tried to prevent ICEs, or something?

Related discussion:
text: .unwrap_or(false); let (res, self_ctor_substs) = if let Res::SelfCtor(impl_def_id) = res { <del> let ty = self.impl_self_ty(span, impl_def_id).ty; let adt_def = ty.ty_adt_def(); </del> <ins> let ty = self.normalize_ty(span, tcx.at(span).type_of(impl_def_id)); </ins> match ty.kind { ty::Adt(adt_def, substs) if adt_def.has_ctor() => { let variant = adt_def.non_enum_variant();
Code change:
Summary from : used as a tuple-struct constructor function should use the fully type-substituted form from the block, but does not. Thus, today this code is accepted, but it should not be. (Fixing this would be a breaking-change, so we should take care in how we deploy it.) Original bug report follows: <!-- 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. --I tried this code: In nightly rustc, compiles while yields a type mismatch error:
The one is incorrect, has all its generic parameters substituted, i.e. it's / in both cases, type or constructor function.
To be 100% clear here: I believe what is saying is that the compiler has a bug, and that the bug is that the code should be treated as a short-hand for: and thus should be yielding the same error that one sees for the cases in the code from the description. However, the code is not yielding an error at all.
T-compiler triage: leaving nominated for T-lang. Tagging as P-high priority to resolve whether the semantics described by is indeed what we want, and if so, how to address deploying a breaking-change to fix it.
cc I thought we had fixed this bug in (and to be clear, it's clearly a bug (as noted by in ). It should not compile.
Just to simplify a bit (still passes but shouldn't):
Just checked on godbolt and it seems to compile in every stable release since it was stabilized (). I haven't looked into the code again, but I don't really understand how didn't cover this. Did we forget to add a test with errors, and only tried to prevent ICEs, or something?

Related discussion:
text: span, "the `Self` constructor can only be used with tuple or unit structs", ); <del> if let Some(adt_def) = adt_def { </del> <ins> if let Some(adt_def) = ty.ty_adt_def() { </ins> match adt_def.adt_kind() { AdtKind::Enum => { err.help("did you mean to use one of the enum's variants?");
Code change:
Summary from : used as a tuple-struct constructor function should use the fully type-substituted form from the block, but does not. Thus, today this code is accepted, but it should not be. (Fixing this would be a breaking-change, so we should take care in how we deploy it.) Original bug report follows: <!-- 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. --I tried this code: In nightly rustc, compiles while yields a type mismatch error:
The one is incorrect, has all its generic parameters substituted, i.e. it's / in both cases, type or constructor function.
To be 100% clear here: I believe what is saying is that the compiler has a bug, and that the bug is that the code should be treated as a short-hand for: and thus should be yielding the same error that one sees for the cases in the code from the description. However, the code is not yielding an error at all.
T-compiler triage: leaving nominated for T-lang. Tagging as P-high priority to resolve whether the semantics described by is indeed what we want, and if so, how to address deploying a breaking-change to fix it.
cc I thought we had fixed this bug in (and to be clear, it's clearly a bug (as noted by in ). It should not compile.
Just to simplify a bit (still passes but shouldn't):
Just checked on godbolt and it seems to compile in every stable release since it was stabilized (). I haven't looked into the code again, but I don't really understand how didn't cover this. Did we forget to add a test with errors, and only tried to prevent ICEs, or something?

Related discussion:
text: <ins> fn main() {} struct S0<T>(T); impl<T> S0<T> { const C: S0<u8> = Self(0); //~^ ERROR mismatched types //~| ERROR mismatched types fn foo() { Self(0); //~^ ERROR mismatched types } } // Testing normalization. trait Fun { type Out; } impl<T> Fun for S0<T> { type Out = Self; } trait Foo<T> { fn foo(); } impl<T> Foo<T> for <S0<T> as Fun>::Out { fn foo() { Self(0); //~ ERROR mismatched types } } struct S1<T, U>(T, U); impl<T> S1<T, u8> { const C: S1<u8, u8> = Self(0, 1); //~^ ERROR mismatched types //~| ERROR mismatched types } struct S2<T>(T); impl<T> S2<T> { fn map<U>(x: U) -> S2<U> { Self(x) //~^ ERROR mismatched types //~| ERROR mismatched types } } </ins>
Code change:
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! And nominating for compiler team prioritization.

Related discussion:
text: <del> Subproject commit 23549a8c362a403026432f65a6cb398cb10d44b7 </del> <ins> Subproject commit d8e6e4cfcd83d555bd7717ea24224b777ed75773 </ins>
Code change:
https://crater- cc
Possibly accidentally injected by Would be good to find out why this is happening, so let's ping cleanup and see if we can bisect / shrink the problem down to something usable for finding a fix.
ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Failed to confirm that is the cause: Seems like it regressed prior to
For code I used:
modify labels: -E-needs-bisection
Reduced example: () Errors:
Split the macro in two parts to make it easier to follow, and removed the special lifetime : () Error: I think we can now modify labels: -E-needs-mcve
I believe that the most probable culprit is , cc
is indeed the culprit, I can reproduce the bug on
This was . Assigning for now until we have a better understanding of what's going on.
Fixed in

Related discussion:
text: /// Checks whether the non-terminal may contain a single (non-keyword) identifier. fn may_be_ident(nt: &token::Nonterminal) -> bool { match *nt { <del> token::NtItem(_) | token::NtBlock(_) | token::NtVis(_) => false, </del> <ins> token::NtItem(_) | token::NtBlock(_) | token::NtVis(_) | token::NtLifetime(_) => false, </ins> _ => true, } }