jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2012 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub trait Foo { } impl Foo for int { } </ins>

Discussion:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.
Change:
// // This has some implications for how we get the predicates available to the anon const // see `explicit_predicates_of` for more information on this <del> let generics = tcx.generics_of(parent_def_id.to_def_id()); </del> <ins> let generics = tcx.generics_of(parent_did); </ins> let param_def_idx = generics.param_def_id_to_index[&param_id.to_def_id()]; // In the above example this would be .params[..N#0] let own_params = generics.params_to(param_def_idx as usize, tcx).to_owned();

Discussion:
<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(effects) -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [adtdestructor] computing impl for [checkwellformed] checking that is well-formed -- label +F-constmutrefs +F-consttrait_impl +F-effects
Regression in of
doesn't require any features actually, rip
Removed irrelevant errors:
Minimized: or
Change:
); err.span_label(lifetime_ref.span, "undeclared lifetime"); let mut suggests_in_band = false; <ins> let mut suggest_note = true; </ins> for missing in &self.missing_named_lifetime_spots { match missing { MissingLifetimeSpot::Generics(generics) => {

Discussion:
In case there is an undeclared lifetime in an ADT deriving a wrong help message is emited causes the following error thx, bye
There are two things here: 1) the suggestion should try and identify spans coming from macro expansion and not suggest changes 2) in this case expands to the following: Note the param, which could avoid having any lifetimes and thing would work correctly. We can probably change the desugaring to not specify the lifetime and then we would avoid the second unnecessary duplicated error. would you happen to know if there's any clear negative in doing 2 above and if not, point me in the right direction in to make that change?
I believe that we can't remove the explicit lifetime here. This would allow for even if is only implemented for .
Change:
<ins> // check-pass #![feature(inherent_associated_types)] #![allow(incomplete_features)] struct S<T>(T); impl<T> S<T> { type P = T; } fn main() { type A = S<()>::P; let _: A = (); } </ins>

Discussion:
<details<summary<bbacktrace</b</summary</details<details<summary<bfull stderr (two panics / backtraces)</b</summary</details: label requires-nightly A-associated-items F-inherentassociatedtypes
Context: The recent PR implemented the resolution of inherent associated types but it appears that parameter substitution was overlooked.
Change:
#[multipart_suggestion( lint_addr_suggestion, style = "verbose", <del> applicability = "machine-applicable" </del> <ins> // FIXME(#53934): make machine-applicable again applicability = "maybe-incorrect" </ins> )] AddrEq { ne: &'a str,

Discussion:
No response The lint is marked able but applying the suggestion fails: ` No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Same problem with
claim
I think this is a known issue with with applying all suggestions even if they are multually exclusive. I'm pretty sure there's nothing to do in the lint, it correctly suggests the two (valid) suggestions, only one of them should be applied.
Well we can either remove one of the suggestions or make the lint MaybeIncorrect or something?
I think this is We can't remove one of the suggestions, they are both necessary. We can however make them for the time being.
That is indeed unfortunate.
Change:
Variants::Single { index } => { // `Variants::Single` on enums with variants denotes that // the enum delegates its layout to the variant at `index`. <del> layout_of_variant(*index) </del> <ins> layout_of_variant(*index, None) </ins> } <del> Variants::Multiple { tag_field, .. } => { </del> <ins> Variants::Multiple { tag, tag_encoding, tag_field, .. } => { </ins> // `Variants::Multiple` denotes an enum with multiple // variants. The layout of such an enum is the disjunction // of the layouts of its tagged variants.

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'', 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'' 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: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
On it! Thanks for the report.
Further minimized:
The cause here is neat. here is niche optimizable, with its second variant being subject to niche optimization. Typically, a niche-optimized enum has one tagless variant, and zero or more tagged variants laid out in the usual manner: the tag is placed, and then the rest of the fields follow. But reveals that's not what happens here. Because is a ZST, is placed at offset , rather than (following the tag). In other words: the tag is co-located with the field. This produces an ICE, because our assumption that fields follow tag is violated (a checked sub panics).
claim
Change:
Some(parent) => parent, None => return Ok((self, false)), }; <ins> if callers.contains(&visible_parent) { return Ok((self, false)); } callers.push(visible_parent); </ins> // HACK(eddyb) this bypasses `path_append`'s prefix printing to avoid // knowing ahead of time whether the entire path will succeed or not. // To support printers that do not implement `PrettyPrinter`, a `Vec` or // linked list on the stack would need to be built, before any printing. <del> match self.try_print_visible_def_path(visible_parent)? { </del> <ins> match self.try_print_visible_def_path_recur(visible_parent, callers)? { </ins> (cx, false) => return Ok((cx, false)), (cx, true) => self = cx, } <ins> callers.pop(); </ins> let actual_parent = self.tcx().parent(def_id); debug!( "try_print_visible_def_path: visible_parent={:?} actual_parent={:?}",

Discussion:
I have three crates: (library), (library), and (binary). has no dependencies, and its is just: has the following dependency and : has the following dependency and : The following error happens running or in crate : Try as I may, I can't manage to make the error happen without putting in every one of those lines and dependencies. EDIT: the bug only requires , not
pre-triage: P-high, removing nomination tag. assigning to self for initial investigation.
(seems to me like the line is not necessary to reproduce the bug?) ((but the nonetheless does remain necessary for reproduction....))
Here is a shell script to compile the files using itself (so we get out of the way) and run the compile of under :
and the backtrace from gives us a pretty good hint as to where we might be infinite-looping: (and so on, for at least 15,000 stack frames...)
(prior to rust 1.35.0, it seems like we might have infinite looped here with no stack overflow. Not 100% sure of that yet; and this test case currently relies on 2018 edition, so its not easy to go back to earlier than 1.31.0)
Also, you can inline the contents of crate a into crate b and preserve the erroneous behavior:
Okay I think I have a solution for this. Hope to post PR today or tomorrow.
Change:
// Unsafe actions are not made legal by taking place in an unsafe trait: *self += 1; //~^ ERROR E0133 <del> //~| NOTE unsafe call requires unsafe function or block </del> <ins> //~| NOTE dereference of raw pointer </ins> } }

Discussion:
Label message always mention "unsafe call", even when nothing is actually called. It should duplicate the main message instead, or use some paraphrase of it. cc
How about this :
I've made a , please check the error messages again :)
Fix in , should be closed.
Change:
let a_poly_sig = a.fn_sig(tcx); let b_poly_sig = b.fn_sig(tcx); <del> // As we don't compare regions, skip_binder is fine. let a_sig = a_poly_sig.skip_binder(); let b_sig = b_poly_sig.skip_binder(); </del> <ins> // We don't compare regions, but leaving bound regions around ICEs, so // we erase them. let a_sig = tcx.erase_late_bound_regions(a_poly_sig); let b_sig = tcx.erase_late_bound_regions(b_poly_sig); </ins> (a_sig.abi, a_sig.unsafety, a_sig.c_variadic) == (b_sig.abi, b_sig.unsafety, b_sig.c_variadic)

Discussion:
<!-- 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</detailsPlayground uses 7-13 nightly still, and the code compiles there:
Hmmm... I can't seem to reproduce this. Windows only, perhaps? Or incremental comp issue? I have the input in a and am running .
followed by reproduces this for me. Might be Windows only, haven't tested elsewhere. edit: my code originally failed in Github Actions using an ubuntu builder so I guess not Windows only.
Yup, fails in WSL, too: <details<summaryBacktrace</summary<p</p</details
It fails on latest nightly for me. Failing version: Working version:
Ahh! I was testing 2022-07-14, which passes. I got confused by the date being 1 day off. Yeah, I can reproduce it now :) Running a bisect.
searched nightlies: from nightly-2022-07-13 to nightly-2022-07-15 regressed nightly: nightly-2022-07-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is yet another rollup; we really need a try build for each rolled up PR... Out of: (Always create elided lifetime parameters for functions) (Stabilize and rexport in ) (Implement lifetime binder for closures) (remove allow(rustc::potentialqueryinstability) in rustcspan) (Give a better error when fails for an optional tool) This looks like cc
This is a variant of the following bug which already happens on stable:
Change:
#![plugin(lint_plugin_test)] #![forbid(test_lint)] //~^ NOTE lint level defined here <del> //~| NOTE `forbid` lint level set here </del> <ins> //~| NOTE `forbid` level set here </ins> fn lintme() { } //~ ERROR item is named 'lintme' <del> #[allow(test_lint)] //~ ERROR allow(test_lint) overruled by outer forbid(test_lint) </del> <ins> #[allow(test_lint)] //~^ ERROR allow(test_lint) overruled by outer forbid(test_lint) //~| NOTE overruled by previous forbid </ins> pub fn main() { lintme(); }

Discussion:
From: src/test/compile- E0453 needs a spanlabel and a spannote changed to a span_label, updating it from: To:
Change:
<ins> error: explicit register arguments cannot have names --> $DIR/x86_64_parse_error.rs:11:18 | LL |         asm!("", a = in("eax") foo); |                  ^^^^^^^^^^^^^^^^^ error: positional arguments cannot follow named arguments or explicit register arguments --> $DIR/x86_64_parse_error.rs:17:36 | LL |         asm!("{1}", in("eax") foo, const bar); |                     -------------  ^^^^^^^^^ positional argument |                     | |                     explicit register argument error[E0435]: attempt to use a non-constant value in a constant --> $DIR/x86_64_parse_error.rs:13:46 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{a}", in("eax") foo, a = const bar); |                                              ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/x86_64_parse_error.rs:15:46 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{a}", in("eax") foo, a = const bar); |                                              ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/x86_64_parse_error.rs:17:42 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{1}", in("eax") foo, const bar); |                                          ^^^ non-constant value error: aborting due to 5 previous errors For more information about this error, try `rustc --explain E0435`. </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. --<!-- 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 --
Regressed in 1.58:
This was , whoops. I can work on this. claim
Change:
0u8 } <ins> // This case was reported in <https://github.com/rust-lang/rust/issues/126547> where it doesn't // make sense to make the "note caller chooses ty for ty param" note if the found type contains // the ty param... fn k<T>(_t: &T) -> T { _t //~^ ERROR mismatched types } </ins> fn main() { f::<()>(); g::<(), ()>;

Discussion:
The statement "the caller chooses a type for which can be different from " is confusing because and are always different. I think it would be best to supress that note when the types only differ in reference-ness. The message was introduced in . No response No response
label +D-confusing
Thanks, that note definitely doesn't make sense. CC (). I suggested to move out of in order to catch more cases but that was a bit too aggressive as can be witnessed here — that's on me. We should replicate some parts of , namely checking that the type param in question does not occur in the return expression type. That did cross my mind back then but I didn't really follow up on that thought for some reason.
Thanks for the cc I'll take a look ~today/tomorrow
Opened to avoid making the note if found return type contains the expected return type (type parameter).
Change:
<ins> error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/dont-canonicalize-re-error.rs:25:26 | LL | impl<A: Sized> Constrain<'missing> for W<A> {} |      -                   ^^^^^^^^ undeclared lifetime |      | |      help: consider introducing lifetime `'missing` here: `'missing,` error[E0119]: conflicting implementations of trait `Tr<'_>` for type `W<_>` --> $DIR/dont-canonicalize-re-error.rs:21:1 | LL | impl<'a, A: ?Sized> Tr<'a> for W<A> {} | ----------------------------------- first implementation here LL | struct W<A: ?Sized>(A); LL | impl<'a, A: ?Sized> Tr<'a> for A where A: Constrain<'a> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `W<_>` error: aborting due to 2 previous errors Some errors have detailed explanations: E0119, E0261. For more information about an error, try `rustc --explain E0119`. </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
Change:
<ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #[feature(macro_rules)]; enum T { A(int), B(uint) } macro_rules! test( ($e:expr) => ( fn foo(t: T) -> int { match t { A(y) => $e, B(y) => $e } } ) ) test!(10 + (y as int)) pub fn main() { foo(A(20)); } </ins>

Discussion:
Having a generic seems to be necessary to exhibit the bug. (Caused .)
Reproduced with . Nominating.
cc me
declining; just-a-bug
cc me; possibly addressed by patch to
This has been fixed, adding a test for it soon.

Nominating well defined.
This seems to be fixed.
Not quite: If you put on the inner module, it works. I think this is actually working as intended: the 'pub' on the item being re-exported is itself the indication of whether it can be seen from outside. Curiously, you can't use it locally (with no anywhere in the file) either. This feels not entirely well defined? Or else I'm not well informed enough to address it. Leaving open until we have Patrick around for subsequent triage.
My two cents: makes sense that a 'd item must be , since that means you don't have to search for a pub use. seems like ought to work though.
accepted for well-defined milestone
This is working now. I think my extraction of privacy from resolve has fixed this. Removing all tags and flagging as needstest.
Change:
<ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #[feature(macro_rules)]; enum T { A(int), B(uint) } macro_rules! test( ($e:expr) => ( fn foo(t: T) -> int { match t { A(y) => $e, B(y) => $e } } ) ) test!(10 + (y as int)) pub fn main() { foo(A(20)); } </ins>

Discussion:
With the following test code: You get an ICE:
Looks quite similar to , which is probably .
After updating for removal of and feature-gating of macros, I don't get ICE any more.
Almost certainly fixed by

This code: Causes the ICE cc
Also a similar, but different error:
I've also confirmed that if everything is defined in the same crate, it all compiles just fine.
This may be related to , although it's a different error message so I'm not sure of it.
This is not related to
I just ran into this myself. One interesting thing I found is that the error happens due to the empty variant. This compiles fine for me:
Appears to be fixed now, flagging as needstest.

To replicate: (Original report follows:) I had code like this: This causes rustc to spin forever. Here's the interesting part of the stack trace:
In my attempt to replicate the bug (on a Mac OS machine), this appears to ICE now rather than hang.
(The fact that it ICE's now rather than diverges is probably thanks to )
Reproduced with
This was fixed at some point, the error message is now: which is exactly what one would expect! Flagging as needstest.
Change:
.. }, _, <del> ) = hir.body(body_id).value.kind </del> <ins> ) = hir_map.body(fn_body_id).value.kind </ins> { let opt_suggestions = path_segment .hir_id

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. --: The internal compiler error does not occur in stable (): The fix for compilation is to use instead of and this also prevents the panic in the nightly version of rustc. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
It would be nice to reproduce this without the async-std dependency.
Slightly smaller:
I bisected far enough to find it regressed between the 9th and 10th, then ran out of disk space :facepalm:
Smaller example without
Here you go. The async part doesn't seem important and the issue still occurs with the versions of and and removed from dependencies: It could probably be reduced in size further but I'm not much of a Rust expert. I suspect anything which triggers that particular compiler error would do the trick.
searched nightlies: from nightly-2021-02-10 to nightly-2021-02-11 regressed nightly: nightly-2021-02-11 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Probably cc In particular looks suspect.
Are functions registered as items in the hir? edit: nvm just saw that someone posted a non-async example
Change:
<ins> struct Process; pub type Group = (Vec<String>, Vec<Process>); fn test(process: &Process, groups: Vec<Group>) -> Vec<Group> { let new_group = vec![String::new()]; if groups.capacity() == 0 { groups.push(new_group, vec![process]); //~^ ERROR this function takes 1 argument but 2 arguments were supplied return groups; } todo!() } fn main() {} </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 <!-- 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 --
searched toolchains through Regression in probably cc
I can look into this claim