jiebi/CodeConvo huggingface dataset:
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. --Strangely enough, the following does not ICE: <!-- 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 occured on nightly However, it appeared to not happen on rustc stable 1.75.0 <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I'm pretty sure this is from , cc
I would also like to add this also causes an ICE, so it's likely that it has to do with type constructors

Discussion:
err.span_suggestion_verbose( *span, "use the type name directly", <del> self.tcx.value_path_str_with_args(*alias_to, e_args), </del> <ins> self.tcx.value_path_str_with_args(e_def.did(), e_args), </ins> Applicability::MaybeIncorrect, ); }

<ins> // Checks that the following does not ICE when constructing type mismatch diagnostic involving // `Self` and const generics. // Issue: <https://github.com/rust-lang/rust/issues/122467> pub struct GenericStruct<const N: usize, T> { thing: T, } impl<T> GenericStruct<0, T> { pub fn new(thing: T) -> GenericStruct<1, T> { Self { thing } //~^ ERROR mismatched types } } pub struct GenericStruct2<const M: usize, T>(T); impl<T> GenericStruct2<0, T> { pub fn new(thing: T) -> GenericStruct2<1, T> { Self { 0: thing } //~^ ERROR mismatched types } } fn main() {} </ins>

<ins> error[E0308]: mismatched types --> $DIR/ice-self-mismatch-const-generics.rs:11:9 | LL | impl<T> GenericStruct<0, T> { |         ------------------- this is the type of the `Self` literal LL |     pub fn new(thing: T) -> GenericStruct<1, T> { |                             ------------------- expected `GenericStruct<1, T>` because of return type LL |         Self { thing } |         ^^^^^^^^^^^^^^ expected `1`, found `0` | = note: expected struct `GenericStruct<_, 1>` found struct `GenericStruct<_, 0>` help: use the type name directly | LL |         GenericStruct::<1, T> { thing } |         ~~~~~~~~~~~~~~~~~~~~~ error[E0308]: mismatched types --> $DIR/ice-self-mismatch-const-generics.rs:20:9 | LL | impl<T> GenericStruct2<0, T> { |         -------------------- this is the type of the `Self` literal LL |     pub fn new(thing: T) -> GenericStruct2<1, T> { |                             -------------------- expected `GenericStruct2<1, T>` because of return type LL |         Self { 0: thing } |         ^^^^^^^^^^^^^^^^^ expected `1`, found `0` | = note: expected struct `GenericStruct2<_, 1>` found struct `GenericStruct2<_, 0>` help: use the type name directly | LL |         GenericStruct2::<1, T> { 0: thing } |         ~~~~~~~~~~~~~~~~~~~~~~ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Update: I forgot to write the command, its I tried this code: I expected to see this happen: compiles fine Instead, this happened: I get an . This does not occur on . <!-- 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
We are also seeing this error with rust + thread sanitiser on x86.
Probably caused by , though the actual bug may be in LLVM. cc
We're seeing a weird bitcode level error in our rustc built against head that root-caused to that same PR FWIW.
It's a tsan bug:
Confirmed that fixes the bug we were seeing too. Thanks for the quick fix!

Discussion:
<del> Subproject commit 84f190a4abf58bbd5301c0fc831f7a96acea246f </del> <ins> Subproject commit 0af6c732ec6ca189cd7725e4a7d4290793046e83 </ins>
Change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'still mutable'', 'thread 'rustc' panicked at 'still mutable'' 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: [associatedtypesforimpltraitsinassociatedfn] creating associated items for opaque types returned by [associateditemdefids] collecting associated items or fields of [associateditems] collecting associated items of [opaquetypesdefinedby] computing the opaque types defined by [typeck] type-checking [analysis] running analysis passes on this crate --
cc , also see for a similar regression fixed by nn
Not sure that was actually fixed. The PR seems entirely unrelated
on a nighty before , this errored with
Oh I think I see how that got "fixed". It bailed out of compilation early enough not to hit the ICE anymore by emitting stashed errors earlier. So it got hidden again, and now it's back againbecause of some subtle change in query ordering. We probably need to run this query explicitly for all traits and impls before the big def id freeze.

Discussion:
tcx.ensure().type_of(def_id); tcx.ensure().impl_trait_header(def_id); tcx.ensure().predicates_of(def_id); <ins> tcx.ensure().associated_items(def_id); </ins> } hir::ItemKind::Trait(..) => { tcx.ensure().generics_of(def_id); tcx.ensure().trait_def(def_id); tcx.at(it.span).super_predicates_of(def_id); tcx.ensure().predicates_of(def_id); <ins> tcx.ensure().associated_items(def_id); </ins> } hir::ItemKind::TraitAlias(..) => { tcx.ensure().generics_of(def_id);

<ins> trait Iterable { type Item; fn iter(&self) -> impl Sized; } // `ty::Error` in a trait ref will silence any missing item errors, but will also // prevent the `associated_items` query from being called before def ids are frozen. impl Iterable for Missing { //~^ ERROR cannot find type `Missing` in this scope fn iter(&self) -> Self::Item {} } fn main() {} </ins>

<ins> error[E0412]: cannot find type `Missing` in this scope --> $DIR/ensure-rpitits-are-created-before-freezing.rs:8:19 | LL | impl Iterable for Missing { |                   ^^^^^^^ not found in this scope error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0412`. </ins>
Change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: should be sized but is not?', 'error: internal compiler error: should be sized but is not?' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
cc
This is incidentally fixed by by making unions always sized.
smaller: The union is currently in fact not sized, but this code assumes that non-struct ADTs must be sized:

Discussion:
<ins> // Regression test for https://github.com/rust-lang/rust/issues/122581 // This used to ICE, because the union was unsized and the pointer casting code // assumed that non-struct ADTs must be sized. union Union { val: std::mem::ManuallyDrop<[u8]>, //~^ ERROR the size for values of type `[u8]` cannot be known at compilation time } fn cast(ptr: *const ()) -> *const Union { ptr as _ } fn main() {} </ins>

<ins> error[E0277]: the size for values of type `[u8]` cannot be known at compilation time --> $DIR/unsized-union-ice.rs:6:10 | LL |     val: std::mem::ManuallyDrop<[u8]>, |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time | = help: within `ManuallyDrop<[u8]>`, the trait `Sized` is not implemented for `[u8]`, which is required by `ManuallyDrop<[u8]>: Sized` note: required because it appears within the type `ManuallyDrop<[u8]>` --> $SRC_DIR/core/src/mem/manually_drop.rs:LL:COL = note: no field of a union may have a dynamically sized type = help: change the field's type to have a statically known size help: borrowed types always have a statically known size | LL |     val: &std::mem::ManuallyDrop<[u8]>, |          + help: the `Box` type always has a statically known size and allocates its contents in the heap | LL |     val: Box<std::mem::ManuallyDrop<[u8]>>, |          ++++                            + error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>
Change:
The following code should optimize to a single store of the new discriminant, but doesn't (). Instead, LLVM copies the value to the stack, copies it again and then writes it back. Interestingly, LLVM optimizes this correctly if a third state without value is . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
lol, looks like this optimizes with but fails to with anything equals or above 2, I think 2 or 3 is the default for builds?
Replacing with also optimizes better: Presumably some issue with MIR inlining; produces the optimal code
The problem is not MIR inlining per se. I think this is the problem was trying to fix in ; if you write your own function without a runtime check, it optimizes fine:
Upstream issue: claim :p
Error: Parsing assign command in failed: ...' claim' ' :p'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
label +llvm-fixed-upstream
Confirmed fixed by , needs codegen test.

Discussion:
<ins> //@ compile-flags: -O //@ min-llvm-version: 19 #![crate_type = "lib"] pub enum State { A([u8; 753]), B([u8; 753]), } // CHECK-LABEL: @update #[no_mangle] pub unsafe fn update(s: *mut State) { // CHECK-NEXT: start: // CHECK-NEXT: store i8 // CHECK-NEXT: ret let State::A(v) = s.read() else { std::hint::unreachable_unchecked() }; s.write(State::B(v)); } </ins>
Change:
This code here has a potential issue: If the Box has a custom allocator, then that will not be checked at all. So whatever is used for, it ignores anything stored in custom allocators. It seems like this is just for a lint, so this is probably not critical, but I guess should still be fixed. Cc -- not sure whom else to ping for coroutine state machine transform things?
Cc (also a regular occurrence in this file's )
Lol sorry, I thought I had clicked enter on a comment but I must've not. Let me rewrite it. Yeah, this is approximately the level of urgency you determined. This code exists for an unstable lint, . I don't expect people to be writing , but technically they could.

Discussion:
debug!("Checking must_not_suspend for {}", ty); match *ty.kind() { <del> ty::Adt(..) if ty.is_box() => { let boxed_ty = ty.boxed_ty(); let descr_pre = &format!("{}boxed ", data.descr_pre); </del> <ins> ty::Adt(_, args) if ty.is_box() => { let boxed_ty = args.type_at(0); let allocator_ty = args.type_at(1); </ins> check_must_not_suspend_ty( tcx, boxed_ty, hir_id, param_env, <del> SuspendCheckData { descr_pre, ..data }, </del> <ins> SuspendCheckData { descr_pre: &format!("{}boxed ", data.descr_pre), ..data }, ) || check_must_not_suspend_ty( tcx, allocator_ty, hir_id, param_env, SuspendCheckData { descr_pre: &format!("{}allocator ", data.descr_pre), ..data }, </ins> ) } ty::Adt(def, _) => check_must_not_suspend_def(tcx, def.did(), hir_id, data),

<ins> //@ edition: 2021 #![feature(must_not_suspend, allocator_api)] #![deny(must_not_suspend)] use std::alloc::*; use std::ptr::NonNull; #[must_not_suspend] struct MyAllocatorWhichMustNotSuspend; unsafe impl Allocator for MyAllocatorWhichMustNotSuspend { fn allocate(&self, l: Layout) -> Result<NonNull<[u8]>, AllocError> { Global.allocate(l) } unsafe fn deallocate(&self, p: NonNull<u8>, l: Layout) { Global.deallocate(p, l) } } async fn suspend() {} async fn foo() { let x = Box::new_in(1i32, MyAllocatorWhichMustNotSuspend); //~^ ERROR allocator `MyAllocatorWhichMustNotSuspend` held across a suspend point, but should not be suspend().await; drop(x); } fn main() {} </ins>

<ins> error: allocator `MyAllocatorWhichMustNotSuspend` held across a suspend point, but should not be --> $DIR/allocator.rs:24:9 | LL |     let x = Box::new_in(1i32, MyAllocatorWhichMustNotSuspend); |         ^ LL | LL |     suspend().await; |               ----- the value is held across this suspend point | help: consider using a block (`{ ... }`) to shrink the value's scope, ending before the suspend point --> $DIR/allocator.rs:24:9 | LL |     let x = Box::new_in(1i32, MyAllocatorWhichMustNotSuspend); |         ^ note: the lint level is defined here --> $DIR/allocator.rs:4:9 | LL | #![deny(must_not_suspend)] |         ^^^^^^^^^^^^^^^^ error: aborting due to 1 previous error </ins>
Change:
Apply this patch: And you'll get this query cycle error: There's a strange call graph here; which is responsible for emitting string slicing panics uses panicky string slicing. From reading the code, I'm pretty confident that the infinite recursion case is actually impossible, but our query cycle detection doesn't know or care, and is supposed to handle this case.
The cycle detection probably doesn't understand intrinsic. The intrinsic is lowered in query, while cycle detection operates on .
That was my instinct as well. What's tripping me up mentally is that with this patch, I can without a cycle error: There's no inside of the cycle detection logic. I think there should be. But I also think that since the latest beta, we accidentally fixed this somehow?
Nightly reproducer:

Discussion:
use rustc_middle::ty::TypeVisitableExt; use rustc_middle::ty::{self, GenericArgsRef, InstanceDef, TyCtxt}; use rustc_session::Limit; <ins> use rustc_span::sym; </ins> // FIXME: check whether it is cheaper to precompute the entire call graph instead of invoking // this query ridiculously often.

let mut calls = FxIndexSet::default(); for bb_data in body.basic_blocks.iter() { let terminator = bb_data.terminator(); <del> if let TerminatorKind::Call { func, .. } = &terminator.kind { </del> <ins> if let TerminatorKind::Call { func, args: call_args, .. } = &terminator.kind { </ins> let ty = func.ty(&body.local_decls, tcx); <del> let call = match ty.kind() { ty::FnDef(def_id, args) => (*def_id, *args), _ => continue, </del> <ins> let ty::FnDef(def_id, generic_args) = ty.kind() else { continue; }; let call = if tcx.is_intrinsic(*def_id, sym::const_eval_select) { let func = &call_args[2].node; let ty = func.ty(&body.local_decls, tcx); let ty::FnDef(def_id, generic_args) = ty.kind() else { continue; }; (*def_id, *generic_args) } else { (*def_id, *generic_args) </ins> }; calls.insert(call); }

<ins> // Regression test for #122659 //@ build-pass //@ compile-flags: -O --crate-type=lib #![feature(core_intrinsics)] #![feature(const_eval_select)] use std::intrinsics::const_eval_select; #[inline] pub const fn f() { const_eval_select((), g, g) } #[inline] pub const fn g() { const_eval_select((), f, f) } </ins>
Change:
searched nightlies: from nightly-2024-03-07 to nightly-2024-03-10 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: aarch64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-nightly -regression-untriaged
I suspect caused this regression, but I don't know how to use to test this pr(I tried some times but all failed). Do you have any ideas about this?
if you use the latest version of cargo-bisect-rustc it will bisect the roll-up for you.
Hi, I'm using the latest version of , but seems that it fails to bisect the roll-up. Here's the complete log: bash cargo bisect-rustc --start 2024-03-08 --end 2024-03-09 
It does bisect to for me. (With this visitor change in particular )
The fix has landed on master. Reopening to track beta backport.
Hi, 1.77.0 has been released, can this be backported to beta now?
I wasn’t at the weekly meeting and I don’t know for sure: is not yet marked as accepted for backport (it may just be an oversight in labeling, I’ll try to find out). Once that is done though, the release team, I believe, will backport it.
updated labels on (sorry for the delay)
That was backported in .

Discussion:
if let ast::ExprKind::Await(_, _) | ast::ExprKind::Yield(_) = e.kind { ControlFlow::Break(()) } else { <del> visit::walk_expr(self, e); ControlFlow::Continue(()) </del> <ins> visit::walk_expr(self, e) </ins> } }

<ins> // Non-regression test for issue #122674: a change in the format args visitor missed nested awaits. //@ edition: 2021 //@ check-pass pub fn f1() -> impl std::future::Future<Output = Result<(), String>> + Send { async { should_work().await?; Ok(()) } } async fn should_work() -> Result<String, String> { let x = 1; Err(format!("test: {}: {}", x, inner().await?)) } async fn inner() -> Result<String, String> { Ok("test".to_string()) } fn main() {} </ins>
Change:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' '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: <!-- 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [checkmodprivacy] checking privacy in top-level module [analysis] running analysis passes on this crate --
this bisects to

Discussion:
impl<'tcx> Visitor<'tcx> for NamePrivacyVisitor<'tcx> { fn visit_nested_body(&mut self, body_id: hir::BodyId) { <del> let old_maybe_typeck_results = self.maybe_typeck_results.replace(self.tcx.typeck_body(body_id)); </del> <ins> let new_typeck_results = self.tcx.typeck_body(body_id); // Do not try reporting privacy violations if we failed to infer types. if new_typeck_results.tainted_by_errors.is_some() { return; } let old_maybe_typeck_results = self.maybe_typeck_results.replace(new_typeck_results); </ins> self.visit_body(self.tcx.hir().body(body_id)); self.maybe_typeck_results = old_maybe_typeck_results; }

<del> //@ known-bug: #122736 fn main_ref() { let array = [(); { let mut x = &0; let mut n = 0; while n < 5 { x = &0; } 0 }]; let mut ptrs: Vec<*const [u8]> = vec![&array[0..0], &array[0..1], &array, &array[1..]]; } fn main() {} </del>

<ins> fn main_ref() { let array = [(); { let mut x = &0; let mut n = 0; while n < 5 { //~^ ERROR constant evaluation is taking a long time x = &0; } 0 }]; let mut ptrs: Vec<*const [u8]> = vec![&array[0..0], &array[0..1], &array, &array[1..]]; } fn main() {} </ins>

<ins> error: constant evaluation is taking a long time --> $DIR/no-ice-on-inference-failure.rs:5:9 | LL | /         while n < 5 { LL | | LL | |             x = &0; LL | |         } | |_________^ | = note: this lint makes sure the compiler doesn't get stuck due to infinite loops in const eval. If your compilation actually takes a long time, you can safely allow the lint. help: the constant being evaluated --> $DIR/no-ice-on-inference-failure.rs:2:22 | LL |       let array = [(); { |  ______________________^ LL | |         let mut x = &0; LL | |         let mut n = 0; LL | |         while n < 5 { ...  | LL | |         0 LL | |     }]; | |_____^ = note: `#[deny(long_running_const_eval)]` on by default error: aborting due to 1 previous error </ins>
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: in is not specified explicitly, the default value is used. I expected to see this happen: LLVM is downloaded from CI, when LLVM version is bumped the new LLVM is downloaded from CI as well. Instead, this happened: LLVM starts building from source code after an LLVM update, instead of being downloaded, unless I remove the build directory and do a fresh build, then it starts downloading from CI again. <!-- 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. --:
Or maybe it's a stage0 toolchain update that triggers this issue, not LLVM update (I observed this today). But I've seen this issue several times in the past as well. cc
The section in is completely empty, nothing is overridden.
Update: LLVM is built from source only on the first build attempt, after that it is correctly downloaded from CI.
This is still an issue that I observe regularly.
There were some issues with the change detection logic for LLVM and I think should fix it. Let's see if it still happens with the next LLVM update.

Discussion:
builder: &Builder<'_>, target: TargetSelection, ) -> Result<LlvmResult, Meta> { <ins> // If we have llvm submodule initialized already, sync it. builder.update_existing_submodule(&Path::new("src").join("llvm-project")); </ins> builder.config.maybe_download_ci_llvm(); // If we're using a custom LLVM bail out here, but we can only use a

} } <ins> // Initialize the llvm submodule if not initialized already. builder.update_submodule(&Path::new("src").join("llvm-project")); </ins> let root = "src/llvm-project/llvm"; let out_dir = builder.llvm_out(target);

Err(m) => m, }; <del> builder.update_submodule(&Path::new("src").join("llvm-project")); </del> if builder.llvm_link_shared() && target.is_windows() { panic!("shared linking to LLVM is not currently supported on {}", target.triple); }

} } <ins> /// Updates the given submodule only if it's initialized already; nothing happens otherwise. pub fn update_existing_submodule(&self, submodule: &Path) { // Avoid running git when there isn't a git checkout. if !self.config.submodules(self.rust_info()) { return; } if GitInfo::new(false, submodule).is_managed_git_subrepository() { self.update_submodule(submodule); } } </ins> /// Executes the entire build, as configured by the flags and configuration. pub fn build(&mut self) { unsafe {