jiebi/CodeConvo huggingface dataset:
Change:
self.ribs[ValueNS].pop(); self.label_ribs.pop(); } <del> self.ribs[ValueNS].pop(); </del> <ins> self.last_block_rib = self.ribs[ValueNS].pop(); </ins> if anonymous_module.is_some() { self.ribs[TypeNS].pop(); }

Discussion:
When the error should mention bindings that are outside of the scope but within the same item <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you think we should suggest in this scenario? My local dev branch will suggest:
I removed it.
Change:
self.cx.parent ); <ins> // Save all state that is specific to the outer function // body. These will be restored once down below, once we've // visited the body. </ins> let outer_ec = mem::replace(&mut self.expr_and_pat_count, 0); let outer_cx = self.cx; let outer_ts = mem::take(&mut self.terminating_scopes); <ins> // The 'pessimistic yield' flag is set to true when we are // processing a `+=` statement and have to make pessimistic // control flow assumptions. This doesn't apply to nested // bodies within the `+=` statements. See #69307. let outer_pessimistic_yield = mem::replace(&mut self.pessimistic_yield, false); </ins> self.terminating_scopes.insert(body.value.hir_id.local_id); if let Some(root_id) = self.cx.root_id {

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. --: Same issue still exists in : and also in : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
T-compiler triage: P-high. Leaving nomination label in place, since I don't want to disrupt WG-async-await workflow.
This does already ICE on 1.39.0
I could further simplify the code as:
However, this code does not cause ICE:
If you can reproduce this without depending on tokio that would be great.
How abot this?
Minimized:
in T-compiler meeting. Keeping as P-high but removing nomination.
OK so I've been investigating this a bit. I am not quite able to write-up mentoring instructions yet because I don't really understand what's going on, but I can leave a few notes. First off, the ICE occurs in the code that is attempting to approximate what values may be live across an . It occurs specifically when you have a structure. The nested async blocks etc are not really needed. For example, this also fails in the same way; The ICE occurs in this match arm: It appears to be related to some logic that is attempting to figure out a "worst case" execution order for instructions: I confess I don't quite follow this logic anymore, but the problem has to do with entering a distinct async block. This code for example does not trigger the failure:
Ah, I think maybe I see the problem here actually -- I suspect the problem is that we need to clear (and then restore) the flag when we recurse into a closure body.
Change:
self.ignore_path_set.as_ref().is_match(path) } <ins> pub(crate) fn emit_stashed_diagnostics(&mut self) -> Option<ErrorGuaranteed> { self.parse_sess.dcx.emit_stashed_diagnostics() } </ins> pub(crate) fn set_silent_emitter(&mut self) { self.parse_sess.dcx = DiagCtxt::with_emitter(silent_emitter()); }

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
Probably a duplicate of , and hopefully will be fixed by .
no, I checked, while is fixed, this one isn't :(
Change:
<del> Subproject commit e9da96eb452aa65e79e2342be700544afe509440 </del> <ins> Subproject commit 6145fe6bac65c38375f1216a565a6cc7deb89a2d </ins>

Discussion:
Since was merged, the std test fails with the following error on windows7: After some further instrumentation, I was able to find out the source of the problem: . This was likely caused by , which reworked the backtracing code on windows to be faster through the use of newer APIs. Unfortunately, not all of those APIs are available in Windows 7. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc is going to land in 1.75 while drops windows <10 support from 1.76. Though to be clear windows 7 is not particularly well supported today, CI only tests windows 10.
While this manifests as a test error, I'm pretty sure there's an actual regression here that can be observed in code, and isn't just a unit test failure. I haven't taken the time to make an actual reproducer, but I think any attempt to print a through its implementation will fail. I'll try to make some code showing the regression tomorrow. Regarding windows7 being not well-supported, I'm well-aware of that. I'm trying to improve on this by running the library/std tests on windows7 every night on some (private) infrastructure, and eventually adding a new (tier3) windows7 target once support is officially dropped in 1.76 so we can continue targeting it.
I agree this is likely a regression, and pinged the author: it’s likely the fact that the PR will not work on windows 7 wasn’t known then, but at the same time it seems it could be accepted if it landed today. It’s likely the panic could be resolved though, or some of the old code brought back for the new tier3 target.
Just to be sure I understand: Do I read correctly that due to the absence of some APIs, the issue won't reproduce on Win10? WG-prioritization assigning priority (). label -I-prioritize +P-low
That is correct, the missing APIs were in version 6.2, which I believe comes built into Windows 8+. At least win10 has it for sure.
I just realized this actually affects the 1.75 beta branch as well, this is a regression from stable to beta.
Once the backtrace PR is merged another PR updating the crate can be merged here with the label.
Change:
unsafe fn data_offset<T: ?Sized>(ptr: *const T) -> isize { // Align the unsized value to the end of the `RcBox`. // Because it is ?Sized, it will always be the last field in memory. <ins> // Note: This is a detail of the current implementation of the compiler, // and is not a guaranteed language detail. Do not rely on it outside of std. </ins> data_offset_align(align_of_val(&*ptr)) }

Discussion:
In the implementation of , we find: (And similarly in with .) Note the comment: Is this actually true, even for instantiations where happens to be ? Does the language guarantee that there exist no type such that the fields of would be re-ordered? Or do we need to add to and ? CC
If this were user-facing code it would be a clear case of "no that's not specified, don't assume that". However, I believe rustc does currently honor this assumption and libstd can of course rely on rustc implementation details. would know best. Note that because unsizing happens with "reorganizing" the struct, the struct with a sized T has to be laid out "as if unsized" from the start. For example, and and many other can all be casted to without touching the , the differences in layout between those are quite constrained (limited to different amounts of paddding to respect alignment, I think?). This reasoning wouldn't apply if there was a type that couldn't ever be involved in unsizing, but I don't think the compiler can ever realistically rule that out locally, and I'm rather certain that it doesn't today.
Ah that’s a good point. The constraint that layout cannot change while unsizing is probably enough indeed.
We should probably add a comment to that effect so "don't assume that" is clearer to everyone.
We should! See
FWIW these are nowadays so this got properly fixed at some point.
Change:
self.mark_as_used_if_union(*adt, fields); } } <ins> hir::ExprKind::Closure(cls) => { self.insert_def_id(cls.def_id.to_def_id()); } </ins> _ => (), }

Discussion:
I tried this code: I expected to see the warning: Instead no warning was reported by the compiler. Observed in nightly, 1.67. Seems like the warning was shown in 1.63 and stopped showing in 1.64.
Bisected to CI has expired so I couldn't automatically bisect further, but looks like a likely candidate
It looks like the issue is that dead code detection doesn't work inside closures and generators (which async functions use in their desugaring) This is denied by 1.63 but allowed on 1.64+. label +regression-from-stable-to-stable Here, the parent of the closure is so checking dead code is skipped.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
error[E0632]: cannot provide explicit generic arguments when `impl Trait` is used in argument position <del> --> $DIR/universal-turbofish-in-method-issue-50950.rs:14:9 </del> <ins> --> $DIR/universal-turbofish-in-method-issue-50950.rs:14:24 </ins> | LL |     evt.handle_event::<TestEvent, fn(TestEvent)>(|_evt| { <del> |         ^^^^^^^^^^^^ </del> <ins> |                        ^^^^^^^^^  ^^^^^^^^^^^^^ explicit generic argument not allowed |                        | |                        explicit generic argument not allowed </ins> error: aborting due to previous error

Discussion:
The spans for this error should point to the generic arguments, not the entire path. See <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
<ins> //@ build-fail fn main() { // MIR encodes this as a reborrow from a promoted constant. // But the array lenth can still be gotten from the type. let slice = &[0, 1]; let _ = slice[2]; //~ ERROR: this operation will panic at runtime [unconditional_panic] } </ins>

Discussion:
<!-- 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: I expected to see this happen: Instead, this happened: Apparently, taking a shared reference of will suppress the lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of (which is ) or modify any data in this example. Note that will trigger the lint properly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
See also .
claim
Note this is a problem because which is supposed to fail to compile but this bug makes it fail at runtime instead
In case no one has dug into it yet, the error is suppressed in but not in and before:
label +regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This is caused by . It only ever worked because the lint ran after optimizations. I made a fix . It specializes the length of arrays as constant, even if the array isn't. I'm going to open a PR when I have time, probably tomorrow. In the long term, I'd like to implement some more extensive tracking of "what parts of a value are constant". For example, the compiler currently assumes that anything that had its reference taken can change, but actually, this can only happen inside (as I understand it).
Labels from the closed duplicate , label A-diagnostics, A-lint, A-mir-opt, T-compiler.
Fixed on stable label E-needs-test
I claim the add test part
This lint only appears on full builds (not check), but this will be fixed once lands.
Reopening because I feel this is not yet solved, see on . As per the , should nail down this issue?
MRE: Also, duplicate of
Another variant of this same issue:
Change:
use rustc_errors::{ codes::*, pluralize, struct_span_code_err, Applicability, Diag, ErrorGuaranteed, }; <del> use rustc_hir as hir; </del> use rustc_hir::def::{DefKind, Res}; use rustc_hir::def_id::{DefId, LocalDefId}; <ins> use rustc_hir::{self as hir, Node}; </ins> use rustc_middle::bug; use rustc_middle::query::Key; use rustc_middle::ty::print::{PrintPolyTraitRefExt as _, PrintTraitRefExt as _};

Discussion:
Given the following code: %20%7B%0A%20%20%20%20let%20%20%3D%20MyIterator%3A%3Anext%3B%0A%20%20%20%20%2F%2Flet%20%20%3D%20MyIterator%3CItem%3D()%3E%3A%3Anext%3B%0A%7D) The current output is: But when when I write , it gets interpreted as comparison expressions like and it fails to compile with a lot of "cannot find value in this scope" and "cannot find crate in the list of imported crates". The suggestion is confusing because it is unclear how to apply it. The error goes away if you use directly: produces the error one would expect: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it gets evaluated as an expression because you are missing a . If you add them, then you get a new error message ():
I see, let me rephrase the issue: The suggestion is "help: specify the associated type: " where "help: specify the associated type: " with a double colon would be correct.
Triage: Suggestion is correct for code using (which all code written in Rust =2021 uses). For code written without in Rust <2021: No change. As mentioned, the suggestion should use an expression-style path (i.e., one with turbofishes).
claim
Working on tests before creating a PR. Multiple tests exist already that have an odd hardcoded expectation for error output, so I'll be double checking those make sense with these changes, and adding a few tests of my own. Otherwise, this really does seem like it was a simple two character fix, unless I missed something somewhere.
Yeah, it's a pretty easy one. Adding before is always correct — not only in expression contexts but also in type contexts since turbofish is also possible in type positions (e.g., ) — albeit redundant. Omitting before in type contexts would be a possible "optimization". However, it really isn't worth doing here.

Consider the following code which is ill-formed even after specifying the assoc ty. () would only be well-formed if we defined an inherent associated type () on which doesn't work yet anyway () and is pretty niche) or once we support arbitrary shorthand projections ().
Change:
Node::Field(field) => icx.to_ty(field.ty), <del> Node::Expr(&Expr { kind: ExprKind::Closure{..}, .. }) => tcx.typeck(def_id).node_type(hir_id), </del> <ins> Node::Expr(&Expr { kind: ExprKind::Closure { .. }, .. }) => { tcx.typeck(def_id).node_type(hir_id) } </ins> Node::AnonConst(_) if let Some(param) = tcx.opt_const_param_of(def_id) => { // We defer to `type_of` of the corresponding parameter

Discussion:
The following code produces several ICEs on both beta and nightly (no necessary). <!-- 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 label F-genericassociatedtypes A-const-generics
This regressed in the last day...
Wait wrong issue
As GATs are stable on beta but not on stable, similar to : label regression-from-stable-to-beta
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> // Regression test for #109072. // Check that we don't ICE when canonicalizing user annotation. trait Lt<'a> { type T; } impl Lt<'missing> for () { //~ ERROR undeclared lifetime type T = &'missing (); //~ ERROR undeclared lifetime } fn main() { let _: <() as Lt<'_>>::T = &(); } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-11 regressed nightly: nightly-2023-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This is "due" to , but probably needs to be passed through silently in the canonicalization code.
reduced via treereduce `
I'd argue that repro is worse than the one provided at the top of the issue, even if it's a few bytes shorter. It introduces a bit of superfluous syntax/unnecessary syntax errors. Here's a denser minimization that avoids the syntax errors (except for the one that actually is the root-cause of the issue):
haha, the original snipped looked like this but I though it looked a little too weird :)
claim
Sorry for the off-topic comment: In response to this feedback I made a wrapper for treereduce that avoids introducing unrelated issues. It also runs for you (when it doesn't remove the ICE), and can output a nice Markdown comment with the reduced program.
Change:
<ins> // run-pass // ignore-emscripten no processes // ignore-sgx no processes // ignore-wasm32-bare no unwinding panic // ignore-avr no unwinding panic // ignore-nvptx64 no unwinding panic use std::env; use std::process::Command; struct Bomb; impl Drop for Bomb { fn drop(&mut self) { std::panic::panic_any(Bomb); } } fn main() { let args = env::args().collect::<Vec<_>>(); let output = match &args[..] { [me] => Command::new(&me).arg("plant the").output(), [..] => std::panic::panic_any(Bomb), }.expect("running the command should have succeeded"); println!("{:#?}", output); let stderr = std::str::from_utf8(&output.stderr); assert!(stderr.map(|v| { v.ends_with("drop of the panic payload panicked") }).unwrap_or(false)); } </ins>

Discussion:
See for an example of the problem. Here we panic without any landing pads available upstack, because we are already the top-most(-ish) frame in the first place. This is UB.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Playground link with full code:
FWIW, Miri does detect this. :)
Change:
} fn const_to_opt_uint(&self, v: &'ll Value) -> Option<u64> { <del> try_as_const_integral(v).map(|v| unsafe { llvm::LLVMConstIntGetZExtValue(v) }) </del> <ins> try_as_const_integral(v).and_then(|v| unsafe { let mut i = 0u64; let success = llvm::LLVMRustConstIntGetZExtValue(v, &mut i); success.then_some(i) }) </ins> } fn const_to_opt_u128(&self, v: &'ll Value, sign_ext: bool) -> Option<u128> {

Discussion:
Array created using repeat expression and returned from a function actually returns . Interestingly the problem does not happen when using the list syntax to create the array. I tried this code: I expected to see this happen: the second should pass Instead, this happened: the second fails screaming that Problem exists on stable, beta and nightly : <details<summaryBacktrace</summary<p</p</details
I wonder if is at fault here. It does look to be inappropriately turning the repeat into a memset (when looking at the llvm IR)
Compiling this: with Yields: Which does not seem right. We shouldn't be emitting a memset to 0 there.
This program hits an LLVM assertion if compiled with an LLVM that has assertions enabled:
This appeared in . Until the sample would code emit a compile error (), maybe that would shadow the error? A bisection between those two stable releases points to a group of old PR but I can't really pinpoint one :/
fails even under 1.26. And before that, i128 didn't even exist. So this has been a problem since 128 bit ints were introduced, as far as I can see.
Thank you for the analysis and the fix :)
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
} fn visit_anon_const(&mut self, c: &'tcx hir::AnonConst) { <ins> // When inline const blocks are used in pattern position, paths // referenced by it should be considered as used. let in_pat = mem::replace(&mut self.in_pat, false); </ins> self.live_symbols.insert(self.tcx.hir().local_def_id(c.hir_id)); intravisit::walk_anon_const(self, c); <ins> self.in_pat = in_pat; </ins> } }

Discussion:
This should compile without warnings (): Yet it warns: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this only occurs in const patterns. This produces no warnings (): Output:
Cc – this only occurs with inline const expressions; no warning is triggered with const items.
claim
Change:
<ins> #![feature(type_alias_impl_trait)] trait Allocator { type Buffer; } struct DefaultAllocator; impl<T> Allocator for DefaultAllocator { //~^ ERROR: the type parameter `T` is not constrained type Buffer = (); } type A = impl Fn(<DefaultAllocator as Allocator>::Buffer); fn foo() -> A { |_| () } fn main() {} </ins>

Discussion:
Compiled with: Using: Gives:
The problem is not tied to box:
No longer ICEs after
Ops, sorry, I reopen until a test is present.

: <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2019-10-03 to nightly-2020-07-05 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
Minified, It seems possible to ICE on stable, though I'm not sure if it counts? <details<summaryStable error</summary</details
The ICE is fixed in the latest nightly, marking as .