jiebi/CodeConvo huggingface dataset:
Change:
false } <ins> fn let_binding_suggestion(&self, err: &mut Diagnostic, ident_span: Span) -> bool { // try to give a suggestion for this pattern: `name = 1`, which is common in other languages let mut added_suggestion = false; if let Some(Expr { kind: ExprKind::Assign(lhs, _rhs, _), .. }) = self.diagnostic_metadata.in_assignment && let ast::ExprKind::Path(None, _) = lhs.kind { let sm = self.r.session.source_map(); let line_span = sm.span_extend_to_line(ident_span); let ident_name = sm.span_to_snippet(ident_span).unwrap(); // HACK(chenyukang): make sure ident_name is at the starting of the line to protect against macros if sm .span_to_snippet(line_span) .map_or(false, |s| s.trim().starts_with(&ident_name)) { err.span_suggestion_verbose( ident_span.shrink_to_lo(), "you might have meant to introduce a new binding", "let ".to_string(), Applicability::MaybeIncorrect, ); added_suggestion = true; } } added_suggestion } </ins> fn find_module(&mut self, def_id: DefId) -> Option<(Module<'a>, ImportSuggestion)> { let mut result = None; let mut seen_modules = FxHashSet::default();

Discussion:
As a python programmer, forgetting a in an assignment to a variable that didn't exist before is an easy mistake to make. () Rust sees two uses of an undefined variable here (E0425 twice): While the second one is fine, in the first case I would have really appreciated a sentence like this: This would helped me as a newcomer to the language, because it does an educated guess what the problem might be and tells me how to fix it. I think the hint should be if the value is assigned to (first error), but not if it is used as an argument (second error). I hope this is the right place and format to file this suggestion, I would appreciate hints if this is not the case. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is the right place, however you should use the "diagnostic" template when creating issues like this. Thanks for the issue though. label +T-compiler +A-diagnostics
claim
Change:
<ins> error[E0585]: found a documentation comment that doesn't document anything --> $DIR/issue-48636.rs:13:5 | LL |     x: u8 |          - help: missing comma here: `,` LL |     /// The id of the parent core |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: doc comments must come before what they document, maybe a comment was intended with `//`? error: aborting due to previous error For more information about this error, try `rustc --explain E0585`. </ins>

Discussion:
I had this code: The actual error of course here, would be that there is a missing comma after the . However the error message given by the compiler was: error: expected , or , found -- | 16 | #[doc = "The id of the parent core"] | ^ | = help: struct fields should be separated by commas This isn't a particularly important issue, but as mentioned by someone I spoke to regarding this error, the error messages given by the compiler are usually very helpful, and I feel it is worth maintaining this standard.
to fix this, should emit the error for a useless doc comment and a missing comma / brace if it encounters both - right now doc comment errors override missing seperators completely. attributes work fine because they are not parsed as a single doc comment token.
Can I take this one if nobody is working on that?
go ahead! Feel free to ask for help if you need. If this is your first contribution, take a look at for setting up the environment.
, Now console output is coming like this Now I have three quick questions for you. 1) In the case when a is missing for middle fields of , should we avoid showing warning, because we have not parsed below fields yet? 2) Should I consider creating a new entry in enum to handle warning? 3) If we have decided to show both and warning, how important it is to show missing warning before warning?
I would elide the missing comma error. Create a PR with in its body so that I'm assigned as reviewer and we can discuss in the context of the code. It seems like you're in the right path. Depending on how the code is laid out, you might be able to try to consume a without failing if it isn't there depending on the success or failure of the previous field.
PR raised
Change:
} }; <ins> // The move path index of the first union that we find. Once this is // some we stop creating child move paths, since moves from unions // move the whole thing. // We continue looking for other move errors though so that moving // from `*(u.f: &_)` isn't allowed. let mut union_path = None; </ins> for (i, elem) in place.projection.iter().enumerate() { let proj_base = &place.projection[..i]; let body = self.builder.body;

Discussion:
The following code ICEs, when it should produce a cannot move error
Worse, the following compiles:
regression from stable-to-beta and stable-to-nightly
triage: P-high
Change:
<ins> #![feature(coerce_unsized)] use std::any::Any; use std::ops::CoerceUnsized; struct Foo<T> { data: Box<T>, } impl<T> CoerceUnsized<Foo<dyn Any>> for Foo<T> {} //~^ ERROR the parameter type `T` may not live long enough fn main() {} </ins>

Discussion:
into causes an internal compiler panic This causes an internal compiler error: This seems related to , except this is using
:
This is not specific to . The following produces the same kind of error.
modify labels: +regression-from-stable-to-stable The ICE happens on stable regardless of having the feature gate or not (the ICE does not requires a nightly compiler to reproduce)
Change:
pub fn expr_to_string(cx: &mut ExtCtxt, expr: Gc<ast::Expr>, err_msg: &str) -> Option<(InternedString, ast::StrStyle)> { // we want to be able to handle e.g. concat("foo", "bar") <del> let expr = cx.expand_expr(expr); </del> <ins> let expr = cx.expander().fold_expr(expr); </ins> match expr.node { ast::ExprLit(l) => match l.node { ast::LitStr(ref s, style) => return Some(((*s).clone(), style)),

Discussion:
I believe this should output the string : But I get this error: Rust version:
Note that standard recursive macros work fine, e.g., And outputs . Maybe the bug here is that expanding macros within other macros is using an older environment that doesn't include the name ?
It's even worse than that. only uses the compiler built-in macros:
I think this might be a dupe of
Does fixing mean that also gets fixed? I wouldn't assume so, but it might be possible depending on the implementation. (Sorry I missed that issue. I searched for 'recursive macro' instead of 'nested macro'!)
both and use , which doesn't work with non-builtin macros.
Right. I'm referring to the recursive aspect. Wasn't sure if that would make a difference. (I just don't know enough about how macros are expanded to know. Pure guesswork on my part.)
Change:
| = help: replace the const parameters with concrete consts <del> error: aborting due to 12 previous errors </del> <ins> error: aborting due to 13 previous errors </ins> For more information about this error, try `rustc --explain E0044`.

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: I think it's just that this attr ICEs when attached to methods and not functions.
claim
Change:
LL |     let cont: u32 = Generator::create(); |                     ^^^^^^^^^^^^^^^^^ cannot call associated function of trait | <del> help: use a fully-qualified path to a specific available implementation (2 found) </del> <ins> help: use a fully-qualified path to a specific available implementation </ins> | LL |     let cont: u32 = </* self type */ as Generator>::create(); |                     +++++++++++++++++++          +

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:
Change:
--> $DIR/issue-28344.rs:10:13 | LL |     let g = BitXor::bitor; <del> |             ^^^^^^ help: specify the associated type: `BitXor<Output = Type>` </del> <ins> |             ^^^^^^ help: specify the associated type: `BitXor::<Output = Type>` </ins> error[E0599]: no function or associated item named `bitor` found for trait object `dyn BitXor<_>` in the current scope --> $DIR/issue-28344.rs:10:21

Discussion:
Given the following code: %20%7B%0A%20%20%20%20let%20%20%3D%20MyIterator%3A%3Anext%3B%0A%20%20%20%20%2F%2Flet%20%20%3D%20MyIterator%3CItem%3D()%3E%3A%3Anext%3B%0A%7D) The current output is: But when when I write , it gets interpreted as comparison expressions like and it fails to compile with a lot of "cannot find value in this scope" and "cannot find crate in the list of imported crates". The suggestion is confusing because it is unclear how to apply it. The error goes away if you use directly: produces the error one would expect: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it gets evaluated as an expression because you are missing a . If you add them, then you get a new error message ():
I see, let me rephrase the issue: The suggestion is "help: specify the associated type: " where "help: specify the associated type: " with a double colon would be correct.
Triage: Suggestion is correct for code using (which all code written in Rust =2021 uses). For code written without in Rust <2021: No change. As mentioned, the suggestion should use an expression-style path (i.e., one with turbofishes).
claim
Working on tests before creating a PR. Multiple tests exist already that have an odd hardcoded expectation for error output, so I'll be double checking those make sense with these changes, and adding a few tests of my own. Otherwise, this really does seem like it was a simple two character fix, unless I missed something somewhere.
Yeah, it's a pretty easy one. Adding before is always correct — not only in expression contexts but also in type contexts since turbofish is also possible in type positions (e.g., ) — albeit redundant. Omitting before in type contexts would be a possible "optimization". However, it really isn't worth doing here.

Consider the following code which is ill-formed even after specifying the assoc ty. () would only be well-formed if we defined an inherent associated type () on which doesn't work yet anyway () and is pretty niche) or once we support arbitrary shorthand projections ().
Change:
<ins> //@ aux-build:foreign-trait-with-assoc.rs extern crate foreign_trait_with_assoc; use foreign_trait_with_assoc::Foo; // Make sure we don't try to call `fn_arg_names` on a non-fn item. impl Foo for Bar {} //~^ ERROR cannot find type `Bar` in this scope fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'DefId(2: ~ core[ef64]::ops::index::Index::Output) does not have a "fnargnames"'', 'thread 'rustc' panicked at 'DefId(2: ~ core[ef64]::ops::index::Index::Output) does not have a "fnargnames"'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [fnargnames] looking up function parameter names for [resolverforlowering_raw] getting the resolver for lowering --
cc
Change:
<del> Subproject commit d43038932adeb16ada80e206d4c073d851298101 </del> <ins> Subproject commit ee7c676fd6e287459cb407337652412c990686c0 </ins>

Discussion:
Results in a crash (after a perfectly reasonable error message): This was tested with rustc 0.1. Building from HEAD on nyus now to try to get a more helpful backtrace and to verify that it hasn't since been fixed.
Here's a more helpful backtrace. Repros at .
Looks exactly like to me.

On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.
Change:
<ins> error[E0583]: file not found for module `config` --> $DIR/suggest-import-ice-issue-127302.rs:3:1 | LL | mod config; | ^^^^^^^^^^^ | = help: to create the module `config`, create file "$DIR/config.rs" or "$DIR/config/mod.rs" = note: if there is a `mod config` elsewhere in the crate already, import it with `use crate::...` instead error: format argument must be a string literal --> $DIR/suggest-import-ice-issue-127302.rs:10:14 | LL |     println!(args.ctx.compiler.display()); |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | help: you might be missing a string literal to format with | LL |     println!("{}", args.ctx.compiler.display()); |              +++++ error[E0425]: cannot find value `args` in this scope --> $DIR/suggest-import-ice-issue-127302.rs:6:12 | LL |     match &args.cmd { |            ^^^^ not found in this scope | help: consider importing this function | LL + use std::env::args; | error[E0532]: expected unit struct, unit variant or constant, found module `crate::config` --> $DIR/suggest-import-ice-issue-127302.rs:7:9 | LL |         crate::config => {} |         ^^^^^^^^^^^^^ not a unit struct, unit variant or constant error: aborting due to 4 previous errors Some errors have detailed explanations: E0425, E0532, E0583. For more information about an error, try `rustc --explain E0425`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
I suspect this could be cc
what's the command line to reproduce it? I build nightly version and cannot reproduce it by only compiling the code. also I checked playground:
Ok, got it, we can not use 2021 edition in the command line.
Change:
// Verify that we can pretty print invalid constants. <ins> #![feature(adt_const_params)] </ins> #![feature(inline_const)] <ins> #![allow(incomplete_features)] </ins> #[derive(Copy, Clone)] #[repr(u32)]

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Heh, I guess wasn't fixed after all. I wonder when it regressed.
That label is for , I do not think it is the right one here.
cargo bisect rustc says this regressed in Perhaps ?
Untagging as a regression, this requires nightly (const generics).
The bug no longer needs the to trigger.
Change:
<del> error: non-binding let on a type that implements `Drop` </del> <ins> error: non-binding let on a type that has a destructor </ins> --> $DIR/issue-119696-err-on-fn.rs:5:5 | LL |     let _ = foo();

Discussion:
I tried this code: I got this warning: However, there is no impl on the type, so the error message is misleading. It is true however that there is a destructor, as defined here: That being said, it's insiginificant for all underlying types (only destructor of and type in the ), so ideally the warning still wouldn't even show. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Well, even if the parameter of is , it still has a side-effect (deallocates memory). I don't think we need this special-casing. I do think the diagnostic is a bit misleading and should just say "has a destructor" or "has side-effects when dropped". Is there a more practical code example for why you'd want to suppress this error? The example you gave is a bit artificial, so it's a hard to motivate why we'd want to suppress this code since it really could be rewritten to be clearer.
claim
Change:
// CHECK-NEXT: define void @naked_with_args(i{{[0-9]+( %0)?}}) pub fn naked_with_args(a: isize) { // CHECK-NEXT: {{.+}}: <del> // CHECK-NEXT: %_1 = alloca i{{[0-9]+}} </del> <ins> // CHECK-NEXT: %a = alloca i{{[0-9]+}} </ins> &a; // keep variable in an alloca // CHECK: ret void }

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
<ins> // Make sure the compiler does not ICE when trying to generate the debuginfo name of a type that // causes a layout error. // This version of the test already ICE'd before the commit that introduce the ICE described in // https://github.com/rust-lang/rust/issues/94961. // compile-flags:-C debuginfo=2 // build-fail // error-pattern: too big for the current architecture // normalize-stderr-64bit "18446744073709551615" -> "SIZE" // normalize-stderr-32bit "4294967295" -> "SIZE" #![crate_type = "rlib"] pub enum Foo<T> { Bar([T; usize::MAX]), } pub fn foo() -> usize { std::mem::size_of::<Foo<u8>>() } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from glacier <!-- 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. --: with cc <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This would previously just throw an error but not "crash": `
I'll look into it. Thanks for the bug report!
Change:
<ins> //@ compile-flags: -Znext-solver trait Tr<'a> {} // Fulfillment in the new solver relies on an invariant to hold: Either // `has_changed` is true, or computing a goal's certainty is idempotent. // This isn't true for `ReError`, which we used to pass through in the // canonicalizer even on input mode, which can cause a goal to go from // ambig => pass, but we don't consider `has_changed` when the response // only contains region constraints (since we usually uniquify regions). // //   In this test: // Implicit negative coherence tries to prove `W<?0>: Constrain<'?1>`, // which will then match with the impl below. This constrains `'?1` to // `ReError`, but still bails w/ ambiguity bc we can't prove `?0: Sized`. // Then, when we recompute the goal `W<?0>: Constrain<'error>`, when // collecting ambiguities and overflows, we end up assembling a default // error candidate w/o ambiguity, which causes the goal to pass, and ICE. impl<'a, A: ?Sized> Tr<'a> for W<A> {} struct W<A: ?Sized>(A); impl<'a, A: ?Sized> Tr<'a> for A where A: Constrain<'a> {} //~^ ERROR conflicting implementations of trait `Tr<'_>` for type `W<_>` trait Constrain<'a> {} impl<A: Sized> Constrain<'missing> for W<A> {} //~^ ERROR use of undeclared lifetime name `'missing` fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors', 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [specializationgraphof] building specialization graph of trait [coherenttrait] coherence checking all impls of trait [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
regression in