jiebi/CodeConvo huggingface dataset:
Code change:
I was attempting to assign directly to the result of a vector's , which caused this error to fire. That is when I discovered that the help section was telling me to do add an extra let to my while statement, which is not syntactically correct. I tried this code: I expected to see this happen: The code would fail to compile and the help message would tell me to dereference the left side, or at the least give me code that was syntactically correct. Instead, this happened: The could failed to compile, and the help message gave syntactically incorrect code as seen in the backtrace section. <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This minifies to which reports and are related I think, since this example produces the ICE mentioned there on stable
label +A-diagnostics +D-invalid-suggestion +T-compiler
claim

Related discussion:
text: <ins> fn main() { while let 1 = 1 { vec![].last_mut().unwrap() = 3_u8; //~^ ERROR invalid left-hand side of assignment } } </ins>
Code change:
I was attempting to assign directly to the result of a vector's , which caused this error to fire. That is when I discovered that the help section was telling me to do add an extra let to my while statement, which is not syntactically correct. I tried this code: I expected to see this happen: The code would fail to compile and the help message would tell me to dereference the left side, or at the least give me code that was syntactically correct. Instead, this happened: The could failed to compile, and the help message gave syntactically incorrect code as seen in the backtrace section. <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This minifies to which reports and are related I think, since this example produces the ICE mentioned there on stable
label +A-diagnostics +D-invalid-suggestion +T-compiler
claim

Related discussion:
text: <ins> error[E0070]: invalid left-hand side of assignment --> $DIR/issue-93486.rs:3:36 | LL |         vec![].last_mut().unwrap() = 3_u8; |         -------------------------- ^ |         | |         cannot assign to this expression error: aborting due to previous error For more information about this error, try `rustc --explain E0070`. </ins>
Code change:
<!-- 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. --rust version: (tried in the playground) This compiles successfully on the stable and beta channels. <!-- 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 --
prioritize nightly-to-beta regression
ICE bisected to searched nightlies: from nightly-2021-12-12 to nightly-2022-02-01 regressed nightly: nightly-2022-01-19 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
I'll take a stab at fixing this, unless (cc: ) wants to! claim feel free to steal this issue from me.
Hmmm actually this might make sense to be a miscompilation now, since it is kind of ambiguous. We probably should default to the old behavior, but not sure if that makes sense goin forward?
So this is two bugs: associated type resolution is ambiguous, because of the conflict between the associated const and the associated type. Probably needs reworking path resolution to prefer types in type position... because only looks for associated types instead of types and consts. I know how to fix (2.), but I'll try to see if I can include something for (1.) as well... Otherwise I'll just put up the one-liner for (2.)
mmm ok this is fair enough, edit: I guess I was just more worried that we'd have to introduce preference for types/consts here which may not have been defined previously
Yeah, my understanding is that types and consts occupy mutually-exclusive positions in well-formed code, but we might not currently have the right information piped into path resolution to prefer resolving one over the other in cases like this. To demonstrate the issue, here is another regression in path resolution, which passes on Stable and fails on Nightly. Not an ICE, but not sure if we should be breaking existing code that compiles. Happy to help work out a fix-forward, or defer that work to you if you're interested in whipping up a fix. Otherwise we might need to roll back (or at least gate its changes to path resolution behind the feature it introduces).
since this only affects nightly, as long as we put in a fix, it should be ok to not rollback, I can try to look into that
Cool! If you're gonna look into it, then I'll give the task to you. release-assignment
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: <ins> error: found associated const `BAR` when type was expected --> $DIR/shadowed-const.rs:19:14 | LL |   const QUX: Self::BAR; |              ^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in

Related discussion:
text: } /// Iterates over the language items in the given crate. <del> fn get_lang_items(self, tcx: TyCtxt<'tcx>) -> &'tcx [(DefId, usize)] { tcx.arena.alloc_from_iter( self.root .lang_items .decode(self) .map(|(def_index, index)| (self.local_def_id(def_index), index)), ) </del> <ins> fn get_lang_items(self) -> impl Iterator<Item = (DefId, usize)> + 'a { self.root .lang_items .decode(self) .map(move |(def_index, index)| (self.local_def_id(def_index), index)) </ins> } /// Iterates over the diagnostic items in the given crate.
Code change:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in

Related discussion:
text: tcx.arena.alloc_slice(&result) } defined_lib_features => { cdata.get_lib_features(tcx) } <del> defined_lang_items => { cdata.get_lang_items(tcx) } </del> <ins> defined_lang_items => { tcx.arena.alloc_from_iter(cdata.get_lang_items()) } </ins> diagnostic_items => { cdata.get_diagnostic_items() } missing_lang_items => { cdata.get_missing_lang_items(tcx) }
Code change:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in

Related discussion:
text: ) -> impl Iterator<Item = (DefId, DefId)> + '_ { self.get_crate_data(cnum).get_inherent_impls() } <ins> /// Decodes all lang items in the crate (for rustdoc). pub fn lang_items_untracked(&self, cnum: CrateNum) -> impl Iterator<Item = DefId> + '_ { self.get_crate_data(cnum).get_lang_items().map(|(def_id, _)| def_id) } </ins> } impl CrateStore for CStore {
Code change:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in

Related discussion:
text: Vec::from_iter(self.resolver.cstore().trait_impls_in_crate_untracked(cnum)); let all_inherent_impls = Vec::from_iter(self.resolver.cstore().inherent_impls_in_crate_untracked(cnum)); <ins> let all_lang_items = Vec::from_iter(self.resolver.cstore().lang_items_untracked(cnum)); </ins> // Querying traits in scope is expensive so we try to prune the impl and traits lists // using privacy, private traits and impls from other crates are never documented in
Code change:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in

Related discussion:
text: self.add_traits_in_parent_scope(impl_def_id); } } <ins> for def_id in all_lang_items { self.add_traits_in_parent_scope(def_id); } </ins> self.all_traits.extend(all_traits); self.all_trait_impls.extend(all_trait_impls.into_iter().map(|(_, def_id, _)| def_id));
Code change:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in

Related discussion:
text: <ins> // no-prefer-dynamic #![feature(lang_items)] #![crate_type = "rlib"] #![no_std] pub struct DerefsToF64(f64); impl core::ops::Deref for DerefsToF64 { type Target = f64; fn deref(&self) -> &Self::Target { &self.0 } } mod inner { #[lang = "f64_runtime"] impl f64 { /// [f64::clone] pub fn method() {} } } #[lang = "eh_personality"] fn foo() {} #[panic_handler] fn bar(_: &core::panic::PanicInfo) -> ! { loop {} } </ins>
Code change:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in

Related discussion:
text: <ins> // Reexport of a structure that derefs to a type with lang item impls having doc links in their // comments. The doc link points to an associated item, so we check that traits in scope for that // link are populated. // aux-build:extern-lang-item-impl-dep.rs #![no_std] extern crate extern_lang_item_impl_dep; pub use extern_lang_item_impl_dep::DerefsToF64; </ins>
Code change:
<!-- 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. --for example: <!-- 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. --: rustc needs to be built with debug assertions!! <!-- 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 --
might be related to
Probably related to (or in the same spirit) -- debuginfo code may not account for non-ZST allocator on .
Actually mentioning that issue, it gives me a probable fix. claim

Related discussion:
text: ty::RawPtr(ty::TypeAndMut { ty: pointee_type, .. }) | ty::Ref(_, pointee_type, _) => { pointer_or_reference_metadata(cx, t, pointee_type, unique_type_id) } <del> ty::Adt(def, _) if def.is_box() => { </del> <ins> // Box<T, A> may have a non-ZST allocator A. In that case, we // cannot treat Box<T, A> as just an owned alias of `*mut T`. ty::Adt(def, substs) if def.is_box() && cx.layout_of(substs.type_at(1)).is_zst() => { </ins> pointer_or_reference_metadata(cx, t, t.boxed_ty(), unique_type_id) } ty::FnDef(..) | ty::FnPtr(_) => subroutine_type_metadata(cx, unique_type_id),
Code change:
<!-- 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. --for example: <!-- 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. --: rustc needs to be built with debug assertions!! <!-- 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 --
might be related to
Probably related to (or in the same spirit) -- debuginfo code may not account for non-ZST allocator on .
Actually mentioning that issue, it gives me a probable fix. claim

Related discussion:
text: <ins> // build-pass // compile-flags: -Cdebuginfo=2 // fixes issue #94725 #![feature(allocator_api)] use std::alloc::{AllocError, Allocator, Layout}; use std::ptr::NonNull; struct ZST; unsafe impl Allocator for &ZST { fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError> { todo!() } unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout) { todo!() } } fn main() { let _ = Box::<i32, &ZST>::new_in(43, &ZST); } </ins>
Code change:
<!-- 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. --for example: <!-- 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. --: rustc needs to be built with debug assertions!! <!-- 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 --
might be related to
Probably related to (or in the same spirit) -- debuginfo code may not account for non-ZST allocator on .
Actually mentioning that issue, it gives me a probable fix. claim

Related discussion:
text: <del> // check-pass </del> <ins> // build-pass </ins> // compile-flags: -Cdebuginfo=2 // fixes issue #94149
Code change:
<!-- 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. --I discovered a compiler error (segfault) in the following code () in which a generic function is called many times with different types. Some changes that avoid the crash: Running with debug mode instead of release Making simpler (e.g. or ) Marking as Removing the generics () Using the same type argument for all calls () For reference, I wrote the code in question because I was curious about whether the compiler would monomorphize multiple copies of the generic function for different types when the implementation does not depend on the type. <!-- 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. --: also the following versions on Rust playground: stable nightly See backtrace. The output looks the same to me and this was too long to submit with two copies. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label I-crash <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
No longer ICEs since
claim

Related discussion:
text: <ins> // run-pass // regression test for issue #94923 // min-llvm-version: 15.0.0 // compile-flags: -C opt-level=3 fn f0<T>(mut x: usize) -> usize { for _ in 0..1000 { x *= 123; x %= 99 } x + 321 // function composition is not just longer iteration } fn f1<T>(x: usize) -> usize { f0::<(i8, T)>(f0::<(u8, T)>(x)) } fn f2<T>(x: usize) -> usize { f1::<(i8, T)>(f1::<(u8, T)>(x)) } fn f3<T>(x: usize) -> usize { f2::<(i8, T)>(f2::<(u8, T)>(x)) } fn f4<T>(x: usize) -> usize { f3::<(i8, T)>(f3::<(u8, T)>(x)) } fn f5<T>(x: usize) -> usize { f4::<(i8, T)>(f4::<(u8, T)>(x)) } fn f6<T>(x: usize) -> usize { f5::<(i8, T)>(f5::<(u8, T)>(x)) } fn f7<T>(x: usize) -> usize { f6::<(i8, T)>(f6::<(u8, T)>(x)) } fn f8<T>(x: usize) -> usize { f7::<(i8, T)>(f7::<(u8, T)>(x)) } fn main() { let y = f8::<()>(1); assert_eq!(y, 348); } </ins>
Code change:
Given the following code (): Rust gives a diagnostic suggesting deriving : However, adding leads the compiler to still give an error about not supporting this. A non-nightly compiler should not give the second error at all; it should only give the first, saying that the only supported types are integers, and . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assigning this to project-const-generics, getting worked on in https://rust-
claim
To fix this issue, you can do the following steps: grep for "forbidden as the type of a const generic parameter" look at that function for a bit change it so that the second error isn't emitted on stable (probably actually change the control flow to start by branching on In case you are interested but need more help to fix this, feel free to reach out to me on
claim

Related discussion:
text: hir::GenericParamKind::Const { ty: hir_ty, default: _ } => { let ty = tcx.type_of(tcx.hir().local_def_id(param.hir_id)); <del> let err_ty_str; let mut is_ptr = true; let err = if tcx.features().adt_const_params { match ty.peel_refs().kind() { </del> <ins> if tcx.features().adt_const_params { let err = match ty.peel_refs().kind() { </ins> ty::FnPtr(_) => Some("function pointers"), ty::RawPtr(_) => Some("raw pointers"), _ => None, <ins> }; if let Some(unsupported_type) = err { tcx.sess.span_err( hir_ty.span, &format!( "using {} as const generic parameters is forbidden", unsupported_type ), ); } if traits::search_for_structural_match_violation(param.span, tcx, ty).is_some() { // We use the same error code in both branches, because this is really the same // issue: we just special-case the message for type parameters to make it // clearer. if let ty::Param(_) = ty.peel_refs().kind() { // Const parameters may not have type parameters as their types, // because we cannot be sure that the type parameter derives `PartialEq` // and `Eq` (just implementing them is not enough for `structural_match`). struct_span_err!( tcx.sess, hir_ty.span, E0741, "`{}` is not guaranteed to `#[derive(PartialEq, Eq)]`, so may not be  used as the type of a const parameter", ty, ) .span_label( hir_ty.span, format!("`{}` may not derive both `PartialEq` and `Eq`", ty), ) .note( "it is not currently possible to use a type parameter as the type of a  const parameter", ) .emit(); } else { struct_span_err!( tcx.sess, hir_ty.span, E0741, "`{}` must be annotated with `#[derive(PartialEq, Eq)]` to be used as  the type of a const parameter", ty, ) .span_label( hir_ty.span, format!("`{}` doesn't derive both `PartialEq` and `Eq`", ty), ) .emit(); } </ins> } } else { <del> match ty.kind() { </del> <ins> let err_ty_str; let mut is_ptr = true; let err = match ty.kind() { </ins> ty::Bool | ty::Char | ty::Int(_) | ty::Uint(_) | ty::Error(_) => None, ty::FnPtr(_) => Some("function pointers"), ty::RawPtr(_) => Some("raw pointers"),