jiebi/CodeConvo huggingface dataset:
Change:
<ins> warning: the feature `specialization` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/coherence-doesnt-use-infcx-evaluate.rs:7:12 | LL | #![feature(specialization)] |            ^^^^^^^^^^^^^^ | = note: see issue #31844 <https://github.com/rust-lang/rust/issues/31844> for more information = help: consider using `min_specialization` instead, which is more stable and complete = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </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
cc you this assertion
Regression in nightly-2023-07-06 Regression in
so this was clearly buggy before and I expect it to be an issue limited to specialization. Going to not look into this further myself for now.
Change:
#[inline] pub fn alloc_from_iter<I: IntoIterator<Item = T>>(&self, iter: I) -> &mut [T] { assert!(mem::size_of::<T>() != 0); <del> let mut iter = iter.into_iter(); let size_hint = iter.size_hint(); match size_hint { (min, Some(max)) if min == max => { // We know the exact number of elements the iterator will produce here let len = min; if len == 0 { return &mut []; } self.ensure_capacity(len); let slice = self.ptr.get(); unsafe { let mut ptr = self.ptr.get(); for _ in 0..len { // Write into uninitialized memory. ptr::write(ptr, iter.next().unwrap()); // Advance the pointer. ptr = ptr.offset(1); // Update the pointer per iteration so if `iter.next()` panics // we destroy the correct amount self.ptr.set(ptr); } slice::from_raw_parts_mut(slice, len) } } _ => { cold_path(move || -> &mut [T] { let mut vec: SmallVec<[_; 8]> = iter.collect(); if vec.is_empty() { return &mut []; } // Move the content to the arena by copying it and then forgetting // the content of the SmallVec unsafe { let len = vec.len(); let start_ptr = self.alloc_raw_slice(len); vec.as_ptr().copy_to_nonoverlapping(start_ptr, len); vec.set_len(0); slice::from_raw_parts_mut(start_ptr, len) } }) } </del> <ins> let mut vec: SmallVec<[_; 8]> = iter.into_iter().collect(); if vec.is_empty() { return &mut []; } // Move the content to the arena by copying it and then forgetting // the content of the SmallVec unsafe { let len = vec.len(); let start_ptr = self.alloc_raw_slice(len); vec.as_ptr().copy_to_nonoverlapping(start_ptr, len); vec.set_len(0); slice::from_raw_parts_mut(start_ptr, len) </ins> } }

Discussion:
I stumbled on this while debugging I tried calling with an iterator which itself allocates on the arena. If that iterator has fixed size (known through ), the allocation goes in the fast path. In that case, the allocation for the range and the recursive allocations get interlaced. The returned pointers are wrong, and valid objects get overwritten. This can lead to undropped objects and infinite loops. A simple fix has been committed to A more intelligent one may be better.
Can you split out the fix (presuming it's to TypedArena itself) from the arena code? It sounds like if we're returning wrong pointers this is a "soundness" bug too, since that method is safe; which is not great. Nominating for compiler team so we can hopefully assign someone to investigate a proper fix.
triage: sounds very bad. has PR. P-high. removing nomination.
Change:
<ins> // compile-flags: -Z mir-opt-level=2 // edition:2018 // build-pass #![feature(async_closure)] use std::future::Future; fn async_closure() -> impl Future<Output = u8> { (async move || -> u8 { 42 })() } fn main() { let _fut = async_closure(); } </ins>

Discussion:
Compiling with I get since two nightlies:
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .
It works now, thank you.
This should be open until the test is .

<!-- 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 is from glaciers , original ticket: The code still ICEs when checking with <!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Triage: It's now compiled fine with the latest nightly, perhaps it's fixed by .

As , the MIR inliner seems to fail when dealing with opaque return types. Test case: Invocation: <details<summaryICE:</summary</details
I'm not sure how async closures desugar, so this could be way off base, but this looks very similar to the other ICEs tracked in . Does this look like another instance of that issue to you?
The immediate cause of this is the fact that we call during inlining: If we do this, we should also be normalizing the substs we pass to , so that we reveal any opaque types. However, it looks like the opaque type occurs within a binder (due the opaque type appearing in the return type of an fn pointer), so I think lazy normalization may be required to fix this in the general case.
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .
Change:
| LL |     let a: i8 *= 1; |               ^^ help: initialize the variable <ins> | = help: if you meant to overwrite, remove the `let` binding </ins> error: can't reassign to an uninitialized variable --> $DIR/let-binop.rs:6:11 | LL |     let b += 1; |           ^^ help: initialize the variable <ins> | = help: if you meant to overwrite, remove the `let` binding </ins> error: can't reassign to an uninitialized variable --> $DIR/let-binop.rs:8:11 | LL |     let c *= 1; |           ^^ help: initialize the variable <ins> | = help: if you meant to overwrite, remove the `let` binding </ins> error: aborting due to 3 previous errors

Discussion:
This code: gives the following error: It's not clear or even close to what the actual problem is. I think it should throw the E0067 error code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Regression test for issue #57611 // Ensures that we don't ICE // FIXME: This should compile, but it currently doesn't #![feature(trait_alias)] #![feature(type_alias_impl_trait)] trait Foo { type Bar: Baz<Self, Self>; fn bar(&self) -> Self::Bar; } struct X; impl Foo for X { type Bar = impl Baz<Self, Self>; //~ ERROR type mismatch in closure arguments //~^ ERROR type mismatch resolving fn bar(&self) -> Self::Bar { |x| x } } trait Baz<A, B> = Fn(&A) -> &B; fn main() {} </ins>

Discussion:
The following code fails to compile (): with the following error If you make this modification, it compiles fine:
I think maybe cc or ?
I wonder whether this is a dupe of ?

Minimised, reproducible example: See Backtrace
Hello I'm getting the same ICE, but without any unstable features. I don't have a minimized example, though, but it may be another data point when searching for the problem. It's this commit: The commit happens with The code is not correct, it wouldn't compile even if the compiler didn't panic. It doesn't happen on stable, but I guess it's because it bails out sooner on closures taking references:
This still produces an error on the latest nightly (not sure if it's supposed to compile or not), but no longer ICEs.
Change:
TypeOfDepthLock(self.local()) } <ins> pub fn layout_of(&self, ty: Ty<'tcx>) -> &'tcx ty::layout::Layout { self.tcx().normalizing_infer_ctxt(traits::Reveal::All).enter(|infcx| { ty.layout(&infcx).unwrap_or_else(|e| { bug!("failed to get layout for `{}`: {}", ty, e); }) }) } </ins> pub fn check_overflow(&self) -> bool { self.shared.check_overflow }

Discussion:
On stable, beta, and nightly, the follow code prints followed by : CC
This is probably for drop flags, in which case it should get fixed by
Reduced:
where would there be a drop flag here?
My point isn't that there is, but that the code assumes all trait objects have drop flags. I could be wrong though, it might be a bug in the alignment logic.
Not fixed by , will have to investigate further.
Uhhhh, the computation starts with: Which is completely wrong, because you want no trailing padding, i.e. should be . EDIT: getting a field pointer might also be broken, needs looking into. EDIT2: to handle the "minimum size" needed to compute the field offset, so that works.
Change:
kind: hir::GenericParamKind::Type { default: Some(ty), .. }, .. }) => vec![*ty], <del> hir::Node::AnonConst(_) if let Some(const_param_id) = tcx.hir().opt_const_param_default_param_def_id(hir_id) </del> <ins> hir::Node::AnonConst(_) => { if let Some(const_param_id) = tcx.hir().opt_const_param_default_param_def_id(hir_id) </ins> && let hir::Node::GenericParam(hir::GenericParam { kind: hir::GenericParamKind::Const { ty, .. }, .. <del> }) = tcx.hir_node_by_def_id(const_param_id) => { vec![*ty] </del> <ins> }) = tcx.hir_node_by_def_id(const_param_id) { vec![*ty] } else { vec![] } </ins> } ref node => bug!("Unexpected node {:?}", node), },

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:35 ~ [f939]::N).1), defid: DefId(0:37 ~ [f939]::N::{constant}), body: BodyId { hirid: HirId(DefId(0:35 ~ [f939]::N).2) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:35 ~ [f939]::N).1), defid: DefId(0:37 ~ [f939]::N::{constant}), body: BodyId { hirid: HirId(DefId(0:35 ~ [f939]::N).2) } })' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [paramenv] computing normalized predicates of [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 --
bisects to
Slightly smaller:
Change:
<ins> error: `#![doc(test(...)]` does not take a literal --> $DIR/doc-test-literal.rs:3:13 | LL | #![doc(test(""))] |             ^^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #82730 <https://github.com/rust-lang/rust/issues/82730> note: the lint level is defined here --> $DIR/doc-test-literal.rs:1:9 | LL | #![deny(warnings)] |         ^^^^^^^^ = note: `#[deny(invalid_doc_attributes)]` implied by `#[deny(warnings)]` error: aborting due to previous error </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. --This is a fuzzed test case, found with and minimized with , and did not find any related issues. I was able to reproduce with a compiler I compiled 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 --<!-- TRIAGEBOT_END --
claim
label +S-bug-has-mcve
Change:
} } } <ins> fn is_multivariant_adt(ty: Ty<'tcx>) -> bool { if let ty::Adt(def, _) = ty.kind() { def.variants.len() > 1 } else { false } } </ins>

Discussion:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
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() {

Discussion:
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.
Change:
use rustc_middle::ty::layout::{HasTyCtxt, LayoutOf}; use rustc_middle::ty::{self, adjustment::PointerCast, Instance, Ty, TyCtxt}; use rustc_span::source_map::{Span, DUMMY_SP}; <ins> use rustc_target::abi::Size; </ins> impl<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>> FunctionCx<'a, 'tcx, Bx> { #[instrument(level = "trace", skip(self, bx))]

Discussion:
Example: This fails in LLVM:
label +C-bug +A-LLVM +requires-nightly
Change:
passes_both_ffi_const_and_pure = `#[ffi_const]` function cannot be `#[ffi_pure]` <del> passes_break_inside_async_block = `{$name}` inside of an `async` block .label = cannot `{$name}` inside of an `async` block .async_block_label = enclosing `async` block </del> passes_break_inside_closure = `{$name}` inside of a closure .label = cannot `{$name}` inside of a closure .closure_label = enclosing closure <ins> passes_break_inside_coroutine = `{$name}` inside `{$kind}` {$source} .label = cannot `{$name}` inside `{$kind}` {$source} .coroutine_label = enclosing `{$kind}` {$source} </ins> passes_break_non_loop = `break` with value from a `{$kind}` loop .label = can only break with a value inside `loop` or breakable block

Discussion:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // aux-build: issue_67893.rs // edition:2018 // dont-check-compiler-stderr // FIXME(#71222): Add above flag because of the difference of stderrs on some env. extern crate issue_67893; fn g(_: impl Send) {} fn main() { g(issue_67893::run()) //~^ ERROR: `std::sync::MutexGuard<'_, ()>` cannot be sent between threads safely } </ins>

Discussion:
When learning async/await feature I was struggling with running multiple tasks simultaneously. Loop causes compiler to crash Github Action crash output: I expected to see this happen: Error message if something goes wrong. Instead, this happened: Compiler crashed Crash happens on macOS rustc 1.40 / Linux rustc 1.40 / Linux rustc 1.39 ( github actions ) :
If you could provide an example that ICEs in e.g. the playground that would be helpful towards fixing the issue. :)
Provided example is pretty small, but it is dependent on tokio and actix-web. I do not know how to create such an example in playground, I do know know how I can replace async tokio::sync::mpsc with standard library which does not have async alternative as far as i know. I have tried to simplify code but then crash disappear. Just putting everything into one file and crash is gone, code wont compile and reasonable errors show up.
Visiting from triage.. we decided that as the first step we should reduce this reproducer to a more self-contained one.
Can repro. Will try and min.
Reduced version so far is here:
This no longer ICEs on the latest nightly.
Let's see if we can shrink further so that we can add a test. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I’ve reduced it quite a bit. Down to dependencies on only. Appears to need 2 crates.

I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.
Change:
if Some(x) = foo {} //~ ERROR cannot find value `x` in this scope if Some(foo) = bar {} //~ ERROR mismatched types if 3 = foo {} //~ ERROR mismatched types <del> //~^ ERROR mismatched types </del> if Some(3) = foo {} //~ ERROR mismatched types }

Discussion:
I thought this code would provide one of the nice suggestions that implemented in , but it doesn't. (By the way, making a reference to will give an ICE because of .) () Errors:
Reopening as per
This is fixed in beta now: It is still quite verbose (too many errors), but we lead people in the right direction.

: <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed in
Cc
Related: this code should probably have a suggestion for (): Currently it produces:
Minimized (): I think this might be caused by the lifetimes.
Never mind! This causes it too, with no lifetimes (): EDIT: removed the type aliases EDIT 2: changed to to make it clearer that they don't need to be the same type EDIT 3: shortened names, removed comment
Assigning and removing as .20.3D.20.2E.2E.2E.60.20expression.E2.80.A6) in the prioritization working group.
Further minimized to this (): Having be a or produces the ICE, but making it an owned does not produce the ICE.
causes the operands to be typechecked twice: I think this has side effects that are causing problems by being applied twice. Commenting out the second makes the ICE go away, but I'm not sure what the best approach for a proper fix is. The effect on the UI suite is rather low: (It still emits this error:)
I tried a couple of things but it seems to me that you hit the nail in the head and we just need to remove the branch. this is caused because one side is seen to be while the other is seen to be or (depending on the case). This is a problem because the left hand side expression should in reality be a pattern instead, but there's no utility to build a pattern from an expression: patterns are built during parsing (due to differences like, being a valid thing there). Because of that it'll be very hard to make the suggestion happen for those cases, much harder than for the ones we already handle.
I think I just found a smaller example (granted, it's not valid code any more, but how is one supposed to know that in case of ICE? ;-) ): (If that's not the same error I'm happy to open a new ICE issue, but to me it looks the same, with all the , the panic at and the conditional destructuring in a loop).
Change:
<ins> error[E0594]: cannot assign to `*input` which is behind a `&` reference --> $DIR/issue-68049-2.rs:9:7 | LL |   fn example(&self, input: &i32); // should suggest here |                            ---- help: consider changing that to be a mutable reference: `&mut i32` ... LL |       *input = self.0; |       ^^^^^^^^^^^^^^^ `input` is a `&` reference, so the data it refers to cannot be written error[E0594]: cannot assign to `self.0` which is behind a `&` reference --> $DIR/issue-68049-2.rs:17:5 | LL |   fn example(&self, input: &i32); // should suggest here |              ----- help: consider changing that to be a mutable reference: `&mut self` ... LL |     self.0 += *input; |     ^^^^^^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be written error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0594`. </ins>

Discussion:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///