jiebi/CodeConvo huggingface dataset:
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. --When compiling on an Apple M1 processor: <!-- 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
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

Related discussion:
text: assert!(rows.iter().all(|r| r.len() == v.len())); <del> // FIXME(Nadrieril): Hack to work around type normalization issues (see #72476). let ty = matrix.heads().next().map_or(v.head().ty(), |r| r.ty()); </del> <ins> let ty = v.head().ty(); </ins> let is_non_exhaustive = cx.is_foreign_non_exhaustive_enum(ty); let pcx = PatCtxt { cx, ty, span: v.head().span(), is_top_level, is_non_exhaustive };
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. --When compiling on an Apple M1 processor: <!-- 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
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

Related discussion:
text: <ins> // check-pass // From https://github.com/rust-lang/rust/issues/72476 // and https://github.com/rust-lang/rust/issues/89393 trait Trait { type Projection; } struct A; impl Trait for A { type Projection = bool; } struct B; impl Trait for B { type Projection = (u32, u32); } struct Next<T: Trait>(T::Projection); fn foo1(item: Next<A>) { match item { Next(true) => {} Next(false) => {} } } fn foo2(x: <A as Trait>::Projection) { match x { true => {} false => {} } } fn foo3(x: Next<B>) { let Next((_, _)) = x; match x { Next((_, _)) => {} } } fn foo4(x: <B as Trait>::Projection) { let (_, _) = x; match x { (_, _) => {} } } fn foo5<T: Trait>(x: <T as Trait>::Projection) { match x { _ => {} } } fn main() {} </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. --When compiling on an Apple M1 processor: <!-- 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
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

Related discussion:
text: <del> // check-pass // From https://github.com/rust-lang/rust/issues/72476 trait A { type Projection; } impl A for () { type Projection = bool; } struct Next<T: A>(T::Projection); fn f(item: Next<()>) { match item { Next(true) => {} Next(false) => {} } } fn main() {} </del>
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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!
Test failures are fixed in rust-lang/miri; all this needs is a submodule sync.

Related discussion:
text: <del> Subproject commit 18667a856596713fc4479f99b96afc7f03aa995c </del> <ins> Subproject commit fa91a89193d26e6a86e2eee1cbaa38cb28ccebe1 </ins>
Code change:
The test fails due to an arithmetic overflow when debug assertions are enabled. The offending code likely intends to use the explicit wrapping math methods, as the test does pass with the overflow. The test was implemented in <details<summaryBacktrace</summary<p</p</details
The overflowing code is To me, it actually seems like the overflow might be a bug. it looks like you this code. Is it incorrect for it to be overflowing?
This is introduced in with guards like near call-site. So I suppose just swapping the order should be sufficient?
Overflowing here is a bug. Given that we haven't seen an index out of bound panics on like 562, I would guess that the actual logic here is correct (so, we underflow, then overflow). I do want to prove to myself that again (and put it in a comment).
If it is really intended then should be used.
Oh, I think I ran into this as well and thought it was due to a local change I had made violating an invariant.
Duplicate of ?
no, that issue is in diagnostics, while this one is in trait resolution. I'll try to get to the diagnostics issue next week
label -I-prioritize
Ah my bad, thanks. I think I've been running in to both issues and conflating them.

Related discussion:
text: fn universe_for(&mut self, debruijn: ty::DebruijnIndex) -> ty::UniverseIndex { let infcx = self.infcx; let index = <del> self.universe_indices.len() - debruijn.as_usize() + self.current_index.as_usize() - 1; </del> <ins> self.universe_indices.len() + self.current_index.as_usize() - debruijn.as_usize() - 1; </ins> let universe = self.universe_indices[index].unwrap_or_else(|| { for i in self.universe_indices.iter_mut().take(index + 1) { *i = i.or_else(|| Some(infcx.create_next_universe()))
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. --: Also checked beta and nightly at : <!-- 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 --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 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: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.

Related discussion:
text: // Save the index of all fields regardless of their visibility in case // of error recovery. self.write_field_index(expr.hir_id, index); <ins> let adjustments = self.adjust_steps(&autoderef); </ins> if field.vis.is_accessible_from(def_scope, self.tcx) { <del> let adjustments = self.adjust_steps(&autoderef); </del> self.apply_adjustments(base, adjustments); self.register_predicates(autoderef.into_obligations()); self.tcx.check_stability(field.did, Some(expr.hir_id), expr.span, None); return field_ty; } <del> private_candidate = Some((base_def.did, field_ty)); </del> <ins> private_candidate = Some((adjustments, base_def.did, field_ty)); </ins> } } ty::Tuple(tys) => {
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. --: Also checked beta and nightly at : <!-- 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 --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 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: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.

Related discussion:
text: } self.structurally_resolved_type(autoderef.span(), autoderef.final_ty(false)); <del> if let Some((did, field_ty)) = private_candidate { </del> <ins> if let Some((adjustments, did, field_ty)) = private_candidate { // (#90483) apply adjustments to avoid ExprUseVisitor from // creating erroneous projection. self.apply_adjustments(base, adjustments); </ins> self.ban_private_field_access(expr, expr_t, field, did); return field_ty; }
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. --: Also checked beta and nightly at : <!-- 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 --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 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: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.

Related discussion:
text: <ins> // edition:2021 mod m { pub struct S { foo: i32 } impl S { pub fn foo(&self) -> i32 { 42 } } } fn bar(s: &m::S) { || s.foo() + s.foo; //~ ERROR E0616 } fn main() {} </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. --: Also checked beta and nightly at : <!-- 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 --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 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: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.

Related discussion:
text: <ins> error[E0616]: field `foo` of struct `S` is private --> $DIR/issue-90483-inaccessible-field-adjustment.rs:11:18 | LL |   || s.foo() + s.foo; |                  ^^^ private field | help: a method `foo` also exists, call it with parentheses | LL |   || s.foo() + s.foo(); |                     ++ error: aborting due to previous error For more information about this error, try `rustc --explain E0616`. </ins>
Code change:
Tracking issue: . The assembler directive allows to treat data as instructions. This allows to generate CPU instructions that are otherwise not possible using assembler commands. It is platform specific and mostly relevant for RISC-V platforms, but I could also find uses for it on MIPS targets as well. More generally speaking, any solution that allows me to produce custom machine code instructions without a performance overhead will be okay for me. The current best workaround is to write the assembler code externally and then link to it. However, this adds the overhead of a function call that cannot be inlined due to the FFI boundary, so this is not acceptable in the long term. See also for some more discussion of my problem.
This will likely work automatically once LLVM supports it. A commit has recently landed () but is not yet in any released version.
label +A-inline-assembly +F-asm
I tried building rust+cargo from source with cherry-picked. Sadly it did not make the error message go away. A good way to check is to use on a minimal example instead. Turns out that I somehow wasn't.
Okay, it actually does work. What is the procedure around Rust's LLVM dependency? How often is it bumped? Is this a candidate for cherry-picking onto rust-llvm?
LLVM procedure is at https://rustc-dev- I think this is a candidate for cherry-picking but someone needs to do the work.

Related discussion:
text: <del> Subproject commit 01c8b654f9a01371414d1fd69cba38b289510a9e </del> <ins> Subproject commit 2b9078f4afae82f60c5ac0fdb4af42d269e2f2f3 </ins>
Code change:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- 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
Seems related to

Related discussion:
text: //! `RETURN_PLACE` the MIR arguments) are always fully normalized (and //! contain revealed `impl Trait` values). <ins> use crate::type_check::constraint_conversion::ConstraintConversion; </ins> use rustc_index::vec::Idx; use rustc_infer::infer::LateBoundRegionConversionTime; use rustc_middle::mir::*; <del> use rustc_middle::traits::ObligationCause; use rustc_middle::ty::{self, Ty}; </del> <ins> use rustc_middle::ty::Ty; </ins> use rustc_span::Span; <del> use rustc_trait_selection::traits::query::normalize::AtExt; </del> <ins> use rustc_span::DUMMY_SP; use rustc_trait_selection::traits::query::type_op::{self, TypeOp}; use rustc_trait_selection::traits::query::Fallible; use type_op::TypeOpOutput; </ins> use crate::universal_regions::UniversalRegions;
Code change:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- 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
Seems related to

Related discussion:
text: let (&normalized_output_ty, normalized_input_tys) = normalized_inputs_and_output.split_last().unwrap(); <ins> debug!(?normalized_output_ty); debug!(?normalized_input_tys); </ins> let mir_def_id = body.source.def_id().expect_local(); // If the user explicitly annotated the input types, extract
Code change:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- 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
Seems related to

Related discussion:
text: .delay_span_bug(body.span, "found more normalized_input_ty than local_decls"); break; } // In MIR, argument N is stored in local N+1. let local = Local::new(argument_index + 1); let mir_input_ty = body.local_decls[local].ty; let mir_input_span = body.local_decls[local].source_info.span; self.equate_normalized_input_or_output( normalized_input_ty,
Code change:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- 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
Seems related to

Related discussion:
text: // If the user explicitly annotated the input types, enforce those. let user_provided_input_ty = self.normalize(user_provided_input_ty, Locations::All(mir_input_span)); self.equate_normalized_input_or_output( user_provided_input_ty, mir_input_ty,
Code change:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- 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
Seems related to

Related discussion:
text: // `rustc_traits::normalize_after_erasing_regions`. Ideally, we'd // like to normalize *before* inserting into `local_decls`, but // doing so ends up causing some other trouble. <del> let b = match self .infcx .at(&ObligationCause::dummy(), ty::ParamEnv::empty()) .normalize(b) { Ok(n) => { debug!("equate_inputs_and_outputs: {:?}", n); if n.obligations.iter().all(|o| { matches!( o.predicate.kind().skip_binder(), ty::PredicateKind::RegionOutlives(_) | ty::PredicateKind::TypeOutlives(_) ) }) { n.value } else { b } } </del> <ins> let b = match self.normalize_and_add_constraints(b) { Ok(n) => n, </ins> Err(_) => { debug!("equate_inputs_and_outputs: NoSolution"); b } }; // Note: if we have to introduce new placeholders during normalization above, then we won't have // added those universes to the universe info, which we would want in `relate_tys`. if let Err(terr) =
Code change:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- 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
Seems related to

Related discussion:
text: } } } <ins> pub(crate) fn normalize_and_add_constraints(&mut self, t: Ty<'tcx>) -> Fallible<Ty<'tcx>> { let TypeOpOutput { output: norm_ty, constraints, .. } = self.param_env.and(type_op::normalize::Normalize::new(t)).fully_perform(self.infcx)?; debug!("{:?} normalized to {:?}", t, norm_ty); for data in constraints.into_iter().collect::<Vec<_>>() { ConstraintConversion::new( self.infcx, &self.borrowck_context.universal_regions, &self.region_bound_pairs, Some(self.implicit_region_bound), self.param_env, Locations::All(DUMMY_SP), ConstraintCategory::Internal, &mut self.borrowck_context.constraints, ) .convert_all(&*data); } Ok(norm_ty) } </ins> }
Code change:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- 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
Seems related to

Related discussion:
text: } struct BorrowCheckContext<'a, 'tcx> { <del> universal_regions: &'a UniversalRegions<'tcx>, </del> <ins> pub(crate) universal_regions: &'a UniversalRegions<'tcx>, </ins> location_table: &'a LocationTable, all_facts: &'a mut Option<AllFacts>, borrow_set: &'a BorrowSet<'tcx>, <del> constraints: &'a mut MirTypeckRegionConstraints<'tcx>, </del> <ins> pub(crate) constraints: &'a mut MirTypeckRegionConstraints<'tcx>, </ins> upvars: &'a [Upvar<'tcx>], }
Code change:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- 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
Seems related to

Related discussion:
text: self.relate_types(sup, ty::Variance::Contravariant, sub, locations, category) } <ins> #[instrument(skip(self, category), level = "debug")] </ins> fn eq_types( &mut self, expected: Ty<'tcx>,
Code change:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- 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
Seems related to

Related discussion:
text: <ins> // check-pass #![feature(generic_associated_types)] use std::marker::PhantomData; trait Family: Sized { type Item<'a>; fn apply_all<F>(&self, f: F) where F: FamilyItemFn<Self> { } } struct Array<T>(PhantomData<T>); impl<T: 'static> Family for Array<T> { type Item<'a> = &'a T; } trait FamilyItemFn<T: Family> { fn apply(&self, item: T::Item<'_>); } impl<T, F> FamilyItemFn<T> for F where T: Family, for<'a> F: Fn(T::Item<'a>) { fn apply(&self, item: T::Item<'_>) { (*self)(item); } } fn process<T: 'static>(array: Array<T>) { // Works array.apply_all(|x: &T| { }); // ICE: NoSolution array.apply_all(|x: <Array<T> as Family>::Item<'_>| { }); } fn main() {} </ins>