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. --I used since just gave a {integer}` error. Don't know if it's related, but thought I should mention it. <!-- 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 nightly-2022-11-03 through nightly-2023-03-31 Regression in nightly-2022-11-06 Regression in Regression in
label F-inherentassociatedtypes claim
I've just pushed a commit to that will fix this issue. Thanks for mentioning. That's just an artifact.
Triage: this is no longer ICE since today's nightly. label: +E-needs-test

Discussion:
<ins> // Regression test for issue #109759. // check-pass #![feature(inherent_associated_types)] #![allow(incomplete_features)] struct Foo; struct Bar<const X: usize>([(); X]); impl<const X: usize> Bar<X> { pub fn new() -> Self { Self([(); X]) } } impl Foo { type Bar<const X: usize> = Bar<X>; } fn main() { let _ = Foo::Bar::<10>::new(); } </ins>

<ins> // check-pass #![feature(inherent_associated_types, generic_const_exprs)] #![allow(incomplete_features)] struct Parent<const O: usize>; impl<const O: usize> Parent<O> { type Mapping<const I: usize> = Store<{ O + I }> where [(); O + I]: ; } struct Store<const N: usize>; impl<const N: usize> Store<N> { const REIFIED: usize = N; fn reify() -> usize { N } } fn main() { let _ = Parent::<2>::Mapping::<{ 12 * 2 }>::REIFIED; let _ = Parent::<1>::Mapping::<{ 2 * 5 }>::reify(); } </ins>
Change:
Hi, Building in release mode with a freshly updated nightly fails with a SIGSEGV (or STATUSACCESSVIOLATION on Windows). This doesn't occur on or , or when building with any profile that has . I stumbled upon this while trying to measure the performance impact of , which branches from at and suffers from the same issue. I don't know why, but the problem only appears on (that I'm aware of): fails, while any other crate within the same repo works (provided they don't depend on )? : The same issue arises with the same version of nightly on Windows. <details<summaryBacktrace</summary<p</p</details
Could you check which nightly and PR caused this regression with ?
Additionally, are you able to get a backtrace with a debugger?
Sure, I'll run the bisect tomorrow morning (CET). I'll try, but if the builds don't already have debug symbols, I'm not sure how to have x.py spit them out. No need to reply if they're already in there, but if they aren't, instructions would be appreciated :)
We do ship debug symbols, they may be in a rustup component instead of shipped by default. rustc-dev, I believe?
Thanks, I'll check that out in roughly 8 hours :)
We do always ship symbols in the same binary, but we never ship debuginfo.
Preliminary reduction for :
Minimized:
Upstream fix:
Thank you so much for taking the issue, I did try bisecting, but you had located the issue by the time I made any progress :)

Discussion:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/16.0-2023-03-06 </del> <ins> branch = rustc/16.0-2023-04-05 </ins> [submodule "src/doc/embedded-book"] path = src/doc/embedded-book url = https://github.com/rust-embedded/book.git

<del> Subproject commit 2b9c52f66815bb8d6ea74a4b26df3410602be9b0 </del> <ins> Subproject commit 585a6eb3ebf7c40fd7c1b23e3ece557b3cc2aa36 </ins>
Change:
Note: the below reduction originally came from a + in the wild. I haven't found a way to demonstrate this outside of the "float inference vars + method" combo, but: works on stable () and beta (), and errors on nightly with: Even though it doesn't show the source for candidate , I'm almost certain it's this: from (cc On the original PR I left comments like , trying to rectify the issues with the original approach, but they didn't go anywhere and the version that one in the end is the (arguably) more fragile original one, that uses blanket s and works around their unwanted interactions. It's possible in this case all it takes is checking for "float inference vars" and making sure they can never be considered to implement , but I'm worried there might be other edge cases lurking in the shadows. Also, did both of those PRs skip crater? I feel like this shouldn't be that hard to hit in the wild.
WG-prioritization assigning priority (). label -I-prioritize +P-high

Discussion:
| ty::Alias(..) | ty::Param(..) | ty::Bound(..) <del> | ty::Error(_) => {} ty::Infer(_) => { </del> <ins> | ty::Error(_) | ty::Infer( ty::InferTy::IntVar(_) | ty::InferTy::FloatVar(_) | ty::InferTy::FreshIntTy(_) | ty::InferTy::FreshFloatTy(_), ) => {} ty::Infer(ty::InferTy::TyVar(_) | ty::InferTy::FreshTy(_)) => { </ins> candidates.ambiguous = true; } }

} struct SelectionCandidateSet<'tcx> { <del> // A list of candidates that definitely apply to the current // obligation (meaning: types unify). </del> <ins> /// A list of candidates that definitely apply to the current /// obligation (meaning: types unify). </ins> vec: Vec<SelectionCandidate<'tcx>>, <del> // If `true`, then there were candidates that might or might // not have applied, but we couldn't tell. This occurs when some // of the input types are type variables, in which case there are // various "builtin" rules that might or might not trigger. </del> <ins> /// If `true`, then there were candidates that might or might /// not have applied, but we couldn't tell. This occurs when some /// of the input types are type variables, in which case there are /// various "builtin" rules that might or might not trigger. </ins> ambiguous: bool, }

<ins> // check-pass trait MyCmp { fn cmp(&self) {} } impl MyCmp for f32 {} fn main() { // Ensure that `impl<F: FnPtr> Ord for F` is never considered for int and float infer vars. 0.0.cmp(); } </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. --See . At line 177 of the generated assembly, it loads the address and passes it to the function. The offset 176 is incorrect since the data pushed to the stack in lines 166-175, the 40-byte stack frame pushed during the interrupt, and the 8-byte error code are only 128 bytes total, so the address will point to something random below the interrupt stack frame on the stack. This does not occur if the error code argument is removed: see . Here, an additional instruction appears at line 175 after saving registers, and the offset used at line 177 is correct (skipping the 80 bytes plus the 72 from the 9 saved registers, for 152 bytes total). Experimenting with custom target JSON specifications instead of x8664-unknown-none, it appears that the bug disappears when the part of the specification is removed.
cc
This regression seems to have been introduced by the LLVM 16 upgrade. searched nightlies: from nightly-2023-03-24 to nightly-2023-05-03 regressed nightly: nightly-2023-03-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This bug seems to have been present in LLVM versions earlier than 16, I'm not sure why this only surfaced now. I'm working on a patch for LLVM.

Discussion:
<del> Subproject commit ea6fa9c2d43aaf0f11559719eda9b54d356d5416 </del> <ins> Subproject commit 533d3f338b804d54e5d0ac4fba6276af23002d9c </ins>
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. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Are you able to fill out the requested details of the crash?
updated
Can you provide the dependencies in use? From what I can tell they aren't supported on Linux, but I'm unsure if I'm looking at the correct crate
tokio 0.1.21
Reduced this a little to It looks like somewhere down the line, a constant is being pretty printed into the .dot with path trimming, which later causes an ICE since no error is actually being emitted

Discussion:
use rustc_index::vec::{Idx, IndexVec}; use rustc_middle::mir::{self, traversal, BasicBlock}; use rustc_middle::mir::{create_dump_file, dump_enabled}; <ins> use rustc_middle::ty::print::with_no_trimmed_paths; </ins> use rustc_middle::ty::TyCtxt; use rustc_span::symbol::{sym, Symbol};

if tcx.sess.opts.unstable_opts.graphviz_dark_mode { render_opts.push(dot::RenderOption::DarkTheme); } <del> dot::render_opts(&graphviz, &mut buf, &render_opts)?; </del> <ins> with_no_trimmed_paths!(dot::render_opts(&graphviz, &mut buf, &render_opts)?); </ins> file.write_all(&buf)?;
Change:
I tried this code: I expected to see this happen: Bootstrap is built, and one process runs tidy while the other says "waiting for build lock" Instead, this happened: <!-- 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. --HEAD is branched from .
I do have a file, but apparently isn't working correctly?
also ran into this on Linux. I'm starting to think locking is just completely broken.
I can confirm it doesn't seem to work on linux. Although it is important to note that still correctly locks, so most things should de-duplicate from anyway.
No, bootstrap has its own locking issues separate from cargo because it deletes and recreates the sysroot. See
Ahh, I'm just seeing the behaviour you saw . At least times 2 doesn't crash and burn lol.
Well... It may very well be . I see a quick fix, just move the lock guard back out of the block.
This might be the cause of supposed "incremental errors" that has occurred to me when rust-analyzer and the command line is running at the same time.

Discussion:
let config = Config::parse(&args); #[cfg(all(any(unix, windows), not(target_os = "solaris")))] <ins> let mut build_lock; #[cfg(all(any(unix, windows), not(target_os = "solaris")))] let _build_lock_guard; #[cfg(all(any(unix, windows), not(target_os = "solaris")))] </ins> { <del> let mut build_lock; let _build_lock_guard; </del> let path = config.out.join("lock"); build_lock = fd_lock::RwLock::new(t!(std::fs::File::create(&path))); _build_lock_guard = match build_lock.try_write() {
Change:
I cloned the Rust repo with the intention of building rustc for cross-compilation to the target. I did the following: selected the "codegen" option the file to append: This failed; the end of the output is as follows: After I executed and retried the build command, the LLVM submodule was checked out and the build was able to make progress. It seems like this should be done automatically. I'm not sure if the issue is specific to this target or if it's happening with other cross-compilation targets. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hmm. This is some interaction between and cross-compiling, but I'm not sure exactly what — it should be a no-op unless you're building for the host. As a workaround you can set and that should handle the submodule automatically.
(Note that is implied by .)
Ok, it looks like we only try to build crtbegin.o for musl targets: So I think we would have checked out the submodule if we were doing a full LLVM build, but because we're only building the CRT it got missed when download-ci-llvm was implemented. I think the simplest fix is to call at the start of , like we do for the step:
looks like it also has the same bug: as well as :
claim
Does fixing also come under the scope of this issue? I'd be happy to fix that as well.
sure thing, feel free to fix all three at once :)
Do I pause work on this till gets resolved? Since it's implementing the workaround you mentioned as a solution
no, this fix still makes sense - not everyone is using the profile without changes.

Discussion:
/// Creates the `rust-src` installer component fn run(self, builder: &Builder<'_>) -> GeneratedTarball { <ins> builder.update_submodule(&Path::new("src/llvm-project")); </ins> let tarball = Tarball::new_targetless(builder, "rust-src"); // A lot of tools expect the rust-src component to be entirely in this directory, so if you

/// Build crtbegin.o/crtend.o for musl target. fn run(self, builder: &Builder<'_>) -> Self::Output { <ins> builder.update_submodule(&Path::new("src/llvm-project")); </ins> let out_dir = builder.native_dir(self.target).join("crt"); if builder.config.dry_run() {

/// Build linunwind.a fn run(self, builder: &Builder<'_>) -> Self::Output { <ins> builder.update_submodule(&Path::new("src/llvm-project")); </ins> if builder.config.dry_run() { return PathBuf::new(); }
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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in cc

Discussion:
tcx, infcx.fresh_substs_for_item(DUMMY_SP, impl_def_id), ); <del> // I guess we don't need to make a universe unless we need it, // but also we're on the error path, so it doesn't matter here. let universe = infcx.create_next_universe(); </del> <ins> let value = tcx.fold_regions(qself_ty, |_, _| tcx.lifetimes.re_erased); // FIXME: Don't bother dealing with non-lifetime binders here... if value.has_escaping_bound_vars() { return false; } </ins> infcx .can_eq( ty::ParamEnv::empty(), impl_.self_ty(), <del> tcx.replace_escaping_bound_vars_uncached(qself_ty, ty::fold::FnMutDelegate { regions: &mut |_| tcx.lifetimes.re_erased, types: &mut |bv| tcx.mk_placeholder(ty::PlaceholderType { universe, bound: bv, }), consts: &mut |bv, ty| tcx.mk_const(ty::PlaceholderConst { universe, bound: bv, }, ty), }) </del> <ins> value, </ins> ) }) && tcx.impl_polarity(impl_def_id) != ty::ImplPolarity::Negative

--> $DIR/missing-assoc-item.rs:6:12 | LL |     for<B> B::Item: Send, <del> |            ^^^^^^^ help: use the fully-qualified path: `<B as IntoIterator>::Item` </del> <ins> |            ^^^^^^^ | help: if there were a trait named `Example` with associated type `Item` implemented for `B`, you could use the fully-qualified path | LL |     for<B> <B as Example>::Item: Send, |            ~~~~~~~~~~~~~~~~~~~~ </ins> error: aborting due to previous error; 1 warning emitted

<ins> // Makes sure we deal with escaping lifetimes *above* INNERMOST when // suggesting trait for ambiguous associated type. impl<I, V> Validator<I> for () where for<'iter> dyn Validator<<&'iter I>::Item>:, //~^ ERROR ambiguous associated type {} pub trait Validator<T> {} fn main() {} </ins>

<ins> error[E0223]: ambiguous associated type --> $DIR/issue-110052.rs:6:30 | LL |     for<'iter> dyn Validator<<&'iter I>::Item>:, |                              ^^^^^^^^^^^^^^^^ help: use the fully-qualified path: `<&'iter I as IntoIterator>::Item` error: aborting due to previous error For more information about this error, try `rustc --explain E0223`. </ins>
Change:
With and the following file: the command fails while installing docs because it can't find the target's directory. This makes sense because the directory is created in one of two places: and both of these are only invoked for the host (in the enclosing impls of each of those call sites, is set to true). So the problem is that the step, which relies on the existence of the directory (see ), is run for the target ( ), but the steps that would create that directory have only been run for the host. I was able to fix this by adding inside the ( ), so that rustc docs aren't generated for the target. I'm not sure if that's the right solution, and in general I'm unsure about the logic for which pieces of documentation are generated for the host and which ones for the target under cross-compilation. The end of the output, showing that fails due to reading a nonexistent directory, is:
n.b. I'm not sure I actually was using correctly -- my goal is to cross-compile snapshots that I can use for bootstrapping Rust on a riscv64 system, and based on the output, I think I probably should have used: instead. But this still shouldn't happen.
I think this will be fixed by
In general RustcDocs is pretty broken, see
merged but this is still unfortunately still an issue :( reproduced with did you ever find a quick workaround?

Discussion:
impl Step for RustcDocs { type Output = Option<GeneratedTarball>; const DEFAULT: bool = true; <ins> const ONLY_HOSTS: bool = true; </ins> fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder;
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. --: Should be able to consistently trigger on Windows platform <details<summaryBacktrace</summary</details
I attempted to create a minimial reproduction based on the code I saw and was not able to get an ICE on the latest nightly (2023-04-09). Could you try updating to the latest nightly and see whether that fixed it? There have been a few issues with transmute that got fixed in the last few days.
This is fixed by

Discussion:
// Unlike `mem::transmute`, a MIR `Transmute` is well-formed // for any two `Sized` types, just potentially UB to run. <del> if !op_ty.is_sized(self.tcx, self.param_env) { </del> <ins> if !self .tcx .normalize_erasing_regions(self.param_env, op_ty) .is_sized(self.tcx, self.param_env) { </ins> self.fail( location, format!("Cannot transmute from non-`Sized` type {op_ty:?}"), ); } <del> if !target_type.is_sized(self.tcx, self.param_env) { </del> <ins> if !self .tcx .normalize_erasing_regions(self.param_env, *target_type) .is_sized(self.tcx, self.param_env) { </ins> self.fail( location, format!("Cannot transmute to non-`Sized` type {target_type:?}"),

<ins> // build-pass // compile-flags: -Zvalidate-mir // edition: 2021 #![crate_type = "lib"] // Use `PhantomData` to get target-independent size async fn get(_r: std::marker::PhantomData<&i32>) { loop {} } pub fn check() { let mut v = get(loop {}); let _ = || unsafe { v = std::mem::transmute([0_u8; 1]); }; } </ins>
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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Correction: () (cc I'm not sure I'll be able to figure it out. searched nightlies: from nightly-2022-06-01 to nightly-2023-04-11 regressed nightly: nightly-2023-03-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details

Discussion:
} if let Some(ty::subst::GenericArgKind::Type(_)) = subst.map(|subst| subst.unpack()) <ins> && let Some(body_id) = self.tcx.hir().maybe_body_owned_by(obligation.cause.body_id) </ins> { <del> let body_id = self.tcx.hir().body_owned_by(obligation.cause.body_id); </del> let mut expr_finder = FindExprBySpan::new(span); expr_finder.visit_expr(&self.tcx.hir().body(body_id).value);

<ins> struct NeedsDropTypes<'tcx, F>(std::marker::PhantomData<&'tcx F>); impl<'tcx, F, I> Iterator for NeedsDropTypes<'tcx, F> //~^ ERROR type annotations needed where F: Fn(&Missing) -> Result<I, ()>, //~^ ERROR cannot find type `Missing` in this scope I: Iterator<Item = Missing>, //~^ ERROR cannot find type `Missing` in this scope {} fn main() {} </ins>

<ins> error[E0412]: cannot find type `Missing` in this scope --> $DIR/issue-110157.rs:6:12 | LL |     F: Fn(&Missing) -> Result<I, ()>, |            ^^^^^^^ not found in this scope error[E0412]: cannot find type `Missing` in this scope --> $DIR/issue-110157.rs:8:24 | LL |     I: Iterator<Item = Missing>, |                        ^^^^^^^ not found in this scope error[E0283]: type annotations needed --> $DIR/issue-110157.rs:3:31 | LL | impl<'tcx, F, I> Iterator for NeedsDropTypes<'tcx, F> |                               ^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for type parameter `I` | = note: cannot satisfy `_: Iterator` note: required for `NeedsDropTypes<'tcx, F>` to implement `Iterator` --> $DIR/issue-110157.rs:3:18 | LL | impl<'tcx, F, I> Iterator for NeedsDropTypes<'tcx, F> |                  ^^^^^^^^     ^^^^^^^^^^^^^^^^^^^^^^^ ... LL |     I: Iterator<Item = Missing>, |        ------------------------ unsatisfied trait bound introduced here error: aborting due to 3 previous errors Some errors have detailed explanations: E0283, E0412. For more information about an error, try `rustc --explain E0283`. </ins>