jiebi/CodeConvo huggingface dataset:
Change:
let rs: Foo = Foo{t: pth}; let unconstrained = break; //~ ERROR: `break` outside of a loop <ins> // This used to ICE because `target_id` passed to `check_expr_break` would be the closure and // not the `loop`, which failed in the call to `find_breakable`. (#65383) 'lab: loop { || { break 'lab; //~ ERROR `break` inside of a closure }; } </ins> }

Discussion:
I tried to compile some massive project and the rust compiler unexpectedly panicked. Luckily, I have managed to replicate the error in a small, reproducible example (still panics on rust playground online, 11 lines of code): I expected a regular error without a panic, but the compiler simply halted. Output of RUSTBACKTRACE=1 rustc -o -C debuginfo=2: Output of :
Maximal reduction: This didn't ICE in 1.37.0 (checked with godbolt).
triage: P-medium (based on assumption that one will always see something like that error message, with its span, before the ICE). Assigning to self for now (but I welcome others who would like to work-steal it). Removing nomination label.
assigning to as well based on insight that this ICE may be arising from diagnostics.
I believe I have a fix. I'll post it after lunch. Edit: faster than I thought.
Change:
<ins> // edition:2021 // compile-flags: -Zdrop-tracking-mir=yes #![feature(generators)] fn main() { let x = &mut (); || { let _c = || yield *&mut *x; || _ = &mut *x; //~^ cannot borrow `*x` as mutable more than once at a time }; } </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
searched toolchains nightly-2023-04-20 through nightly-2023-04-28 Regression in nightly-2023-04-21 searched toolchains through Regression in :thinking: cc
Well, it is not unreachable it turns out huh
I believe this is a MRE:
Change:
crate def: &'hir hir::VariantData<'hir>, } <del> // For Macro we store the DefId instead of the NodeId, since we also create // these imported macro_rules (which only have a DUMMY_NODE_ID). crate struct Macro { crate name: Symbol, crate def_id: hir::def_id::DefId, crate matchers: Vec<Span>, crate imported_from: Option<Symbol>, } </del> #[derive(Debug)] crate struct Import<'hir> { crate name: Symbol,

Discussion:
See for []: ! But when you click on : Or for []: ! With source: Or for [], which is not a built-in: ! []: []: []: modify labels: T-rustdoc C-bug
Related:
I have a hunch that and are both represented as and/or .
Cc
I would experiment to see if that is what's causing it, but I'm waiting on a build for something else
https://rustc-dev-
Wow, I never noticed that! That's so cool :)
Indeed, changing changed the output. See if you can notice my experimental change ;) ! And for a built-in: !
Change:
has_self: bool, inputs: impl Iterator<Item = (Option<&'ast Pat>, &'ast Ty)>, ) -> Result<LifetimeRes, (Vec<MissingLifetime>, Vec<ElisionFnParameter>)> { <del> let outer_candidates = replace(&mut self.lifetime_elision_candidates, Some(Default::default())); </del> <ins> enum Elision { /// We have not found any candidate. None, /// We have a candidate bound to `self`. Self_(LifetimeRes), /// We have a candidate bound to a parameter. Param(LifetimeRes), /// We failed elision. Err, } </ins> <del> let mut elision_lifetime = None; let mut lifetime_count = 0; </del> <ins> // Save elision state to reinstate it later. let outer_candidates = self.lifetime_elision_candidates.take(); // Result of elision. let mut elision_lifetime = Elision::None; // Information for diagnostics. </ins> let mut parameter_info = Vec::new(); <ins> let mut all_candidates = Vec::new(); </ins> let mut bindings = smallvec![(PatBoundCtx::Product, Default::default())]; for (index, (pat, ty)) in inputs.enumerate() {

Discussion:
Instead, this happened: Successful compilation Tested on the playground, all versions and editions. Stable channel: 1.64.0 Beta channel: 1.65.0-beta.3 (2022-10-10 ) Nightly channel: 1.66.0-nightly (2022-10-19 ) I'm labeling this as a regression as I believe it is severe enough of an unplanned change (at best an accidental stabilization?) that I should draw attention to it, even though I haven't found a way to cause miscompilation for example. I also have not tried to do so at all yet. label +T-compiler +A-lifetimes +regression-from-stable-to-stable <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-01-01 to nightly-2022-10-01 regressed nightly: nightly-2022-07-26 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: </details
claim
Actually, this behavior is correct as : There is exactly one lifetime used in the parameters (), so assigning it to the output lifetime is as expected. release-assignment
That verbiage but it compiles on no stable version of rustc prior to 1.64, so I don't think it's actually relevant. (The reference is also explicitly non-normative.) mirrors in specifying input positions, not counts. Regardless of documentation, as something that has not compiled on Rust 1.0--1.63 but compiles today, this is clearly a change in language behavior without FCP which I believe to be unintentional. label +T-lang
Ok, so we will consider this for now a regression that should be backported to stable (we're ~2 weeks away from the new release). WG-prioritization assigning priority (). label -I-prioritize +P-critical
Filed
Nominating for lang team to figure out what we should do with this. Will also ping on zulip.

Discussed in lang, dropping nomination. Agreement that we want to revert the change in behavior and backport that to 1.65 (and 1.64, but that's not happening given short time window). Considering whether we want to make the behavior change can happen in a follow-up proposal.
Change:
<ins> error[E0277]: the trait bound `for<'b> &'b S: Trait` is not satisfied --> $DIR/imm-ref-trait-object-literal-bound-regions.rs:17:5 | LL | fn foo<X>(_: X) |    --- required by a bound in this LL | where LL |     for<'b> &'b X: Trait, |                    ----- required by this bound in `foo` ... LL |     foo::<S>(s); |     ^^^^^^^^ the trait `for<'b> Trait` is not implemented for `&'b S` | = help: the following implementations were found: <&'a mut S as Trait> error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Using a built from commit with debug assertions enabled ( in ), I'm seeing an internal compiler error on the following input (found by ):
: The second error should probably not be emitted as I believe it is caused by a placeholder lifetime used during recovery. We should introduce (or use if it is already there) a lifetime equivalent to .
This only happens in builds with debug assertions. It's not fixed in master.
Assigning as and removing .
Change:
Basic usage: ``` <del> ", $Feature, "#![feature(saturating_neg)] assert_eq!(100", stringify!($SelfT), ".saturating_abs(), 100); </del> <ins> ", $Feature, "assert_eq!(100", stringify!($SelfT), ".saturating_abs(), 100); </ins> assert_eq!((-100", stringify!($SelfT), ").saturating_abs(), 100); assert_eq!(", stringify!($SelfT), "::MIN.saturating_abs(), ", stringify!($SelfT), "::MAX);

Discussion:
It would be great to have and functions for signed integer types. The current work-around is using a pattern like but having explicit functions would lift the corner-case knowledge "burden" from the user.
What do you expect them to return? Just for the two values that can't be expressed? IMHO you should prefer the instead and explicitly handle that.
The and functions both have a corner case when the negative minimum value is used (e.g. -128 for type i8). The result cannot be represented within the bounds of the output type. The / variants shall return a best-effort value (like 127 in case of -128 i8 input), similar to the existing functions. asserteq!(127i8.saturatingabs(), 127); asserteq!(-127i8.saturatingabs(), 127); asserteq!(-128i8.saturatingabs(), 127); asserteq!(127i8.saturatingneg(), -127); asserteq!(-127i8.saturatingneg(), 127); asserteq!(-128i8.saturating_neg(), 127);
These seems reasonable. I'd suggest just making a PR with them unstable and seeing what libs says. By using they'll automatically get the new saturating implementation, too, which should be better for optimization and codegen than the approach.
Haven't done a PR for Rust yet so will take a look at the contribution guidelines and try to get along.
What's holding up stabilization on this? It seems relatively simple.
In my opinion there is nothing specific holding this up from being stabilized. Initially I wanted to give it some time for others to comment, then forgot about. Added a PR for stabilization now.
Change:
<ins> error[E0728]: `await` is only allowed inside `async` functions and blocks --> $DIR/issue-62009.rs:8:5 | LL | fn main() { |    ---- this is not `async` LL |     async { let (); }.await; |     ^^^^^^^^^^^^^^^^^^^^^^^ only allowed inside `async` functions and blocks error[E0728]: `await` is only allowed inside `async` functions and blocks --> $DIR/issue-62009.rs:10:5 | LL |   fn main() { |      ---- this is not `async` ... LL | /     async { LL | | LL | |         let task1 = print_dur().await; LL | |     }.await; | |___________^ only allowed inside `async` functions and blocks error[E0728]: `await` is only allowed inside `async` functions and blocks --> $DIR/issue-62009.rs:14:5 | LL | fn main() { |    ---- this is not `async` ... LL |     (async || 2333)().await; |     ^^^^^^^^^^^^^^^^^^^^^^^ only allowed inside `async` functions and blocks error[E0728]: `await` is only allowed inside `async` functions and blocks --> $DIR/issue-62009.rs:16:5 | LL | fn main() { |    ---- this is not `async` ... LL |     (|_| 2333).await; |     ^^^^^^^^^^^^^^^^ only allowed inside `async` functions and blocks error[E0277]: the trait bound `[closure@$DIR/issue-62009.rs:16:5: 16:15]: std::future::Future` is not satisfied --> $DIR/issue-62009.rs:16:5 | LL |     (|_| 2333).await; |     ^^^^^^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `[closure@$DIR/issue-62009.rs:16:5: 16:15]` | = note: required by `std::future::poll_with_tls_context` error: aborting due to 5 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Hi I'm pretty new to rust and programming in general. I was trying (failing) to write some toy async code and I got this internal compiler error, the theme seems to be always report ICEs so here we go This was from cargo: ~ The code I was trying was this code: ~ <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
ICEs with any statement between while inside a function that isn't async ICE Error without and without the ICE statement inside async function
claim
This is actually the same as . I think I've got a fix for both.
do you have a PR for this open?
Closing as a duplicate of , both of which are fixed by

<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Not had a lot of time to look at this unfortunately and it appears has come up with a fix in in the meantime. release-assignment
claim
assign (Sorry for the noise, testing a new GH feature)
Change:
} ast::PatEnum(..) | ast::PatIdent(_, _, None) => { match tcx.def_map.borrow().find(&pat.id) { <del> Some(&def::DefFn(..)) | </del> Some(&def::DefStruct(..)) => true, _ => false }

Discussion:
compiles fine (other than the dead code warning for ), but is not:
I hit this as well, I would love a fix :+1:
Change:
self.lifetime().is_some() } <ins> /// Returns `true` if the token is a identifier whose name is the given /// string slice. pub fn is_ident_named(&self, name: &str) -> bool { match self.ident() { Some((ident, _)) => ident.name.as_str() == name, None => false } } </ins> /// Returns `true` if the token is a documentation comment. pub fn is_doc_comment(&self) -> bool { match *self {

Discussion:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `
Change:
use rustc_middle::{bug, span_bug}; use rustc_session::config::{self, DebugInfo}; use rustc_span::symbol::{Interner, Symbol}; <del> use rustc_span::{self, FileName, SourceFileHash, Span}; </del> <ins> use rustc_span::{self, SourceFile, SourceFileHash, Span}; </ins> use rustc_target::abi::{Abi, Align, DiscriminantKind, HasDataLayout, Integer, LayoutOf}; use rustc_target::abi::{Int, Pointer, F32, F64}; use rustc_target::abi::{Primitive, Size, VariantIdx, Variants};

Discussion:
shows a pretty big regression between and . I don't know if this is expected, but I'm putting this out there in case others see the dent in perf charts and wonder what had happened. <hr/EDIT( we how have a for . , the other PR in the range, (but only for a small subset of runs).
cc
The range is so the candidates are: "Make the rustc respect the flag in incremental mode." "Add hash of source files in debug info" EDIT: oops, missed - so it's likely . Slow MD5 implementation? I'm curious, why does (merge commit for ) not have its own perf run? Is there a way to trigger one now?
is in the queue:
It looks like this was caused by . I'll start investigating why. I timed several compilations of locally in debug with and without .
For the record, from . I'll update the issue description to minimize potential confusion. Two things I'm seeing: are way worse regressions than , you can focus on the worse ones to get better contrast in measurements (e.g. even has "patched incremental" runs slowed down a lot, unlike many others, being another example I guess) detailed profile (if you click the percentage for a run) shows a lot of LLVM differences, e.g. for , and most of the regressions are , with effectively no ones, so I think we might be able to get away without a revert, just adding a flag controlling whether LLVM sees these hashes (assuming that's the source of the slowdown)
We have (), which at a glance looks right. looks like noise, and so does , so I believe this confirms the fix is complete. For the cost of MD5 hashing compared to SipHash, based on the changes to runs in the original regression, it looks insignificant.
Change:
<ins> // Recover from using a colon as a path separator. use std::process:Command; //~^ ERROR expected `::`, found `:` use std:fs::File; //~^ ERROR expected `::`, found `:` use std:collections:HashMap; //~^ ERROR expected `::`, found `:` //~| ERROR expected `::`, found `:` fn main() { } </ins>

Discussion:
I tried this code: I expected to see this happen: I expected to see two diagnostic messages, telling me about the distinct parse errors on lines 1 and 2. Instead, this happened: The first error was treated as non-recoverable, yielding this output (): I'm assuming recovering in the face of this parse error would be a relatively simple task, given that there is already the present that should be a strong hint that someone meant to type . So I'm tagging this with labels indicating that its a good opportunity for someone who wants to acquaint themselves with the code base. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(This needs a mentor. I am thinking that if someone doesn't pick it up by Friday, then I will see about using it as the basis for one or more instructional videos.)
I can mentor whoever wants to work on this. See for the general area where changes need to be made, and ping me if someone needs help on Zulip.
May I work on this?
You can , and I recommend checking out the to find out what the contribution process looks like.
i would like to work on this with your help.
claim
release-assignment
This is mostly about adding checks around such that it recovers when encountering . However, we would also need the ability to recover to be configurable as arguments to , as we would want to recover from as well. PS: don't take this as is.. I am not that familiar with ast and recovery, but I think this is the main idea
I will take a quick look into this. claim
Change:
// run-pass <ins> #![allow(unused_parens)] </ins> #![allow(non_upper_case_globals)] #![allow(dead_code)] // exec-env:RUST_MIN_STACK=16000000

Discussion:
It doesn't give a warning for the unnecessary parentheses for N1: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
implemented for to check the .
claim
I've encountered an issue I'm not quite sure how to handle :( After getting what looks like a correct solution up with: I am met with the following after starting to build stage-1: Should I open a separate Issue & PR to deal with any errors generated by unused parens or is it within the scope of this issue (and PR coming soon once I write the UI tests) to deal with them?
should be fixed within this issue, and don' forget to add a testcase named into , then , git add the new and updated if any.
I resolved the issue with the submodule, is it alright if I claim this? It's a small patch to land. claim
Change:
// the driver creates (using several `rustc_*` crates). // // The result of query must implement Clone. They must also implement ty::maps::values::Value <del> // which produces an appropiate error value if the query resulted in a query cycle. </del> <ins> // which produces an appropriate error value if the query resulted in a query cycle. </ins> // Queries marked with `fatal_cycle` do not need that implementation // as they will raise an fatal error on query cycles instead. define_maps! { <'tcx>

Discussion:
It's not clear yet whether mir interpretation is the culprit or some changes that crept into the same PR. Perf data: cc [ ] tuple-stress max: 109.4% clean-incremental is a 100% hit! The rest are small. [ ] tuple-stress-opt max: 109.1% same, clean-incremental is a 100% hit! [ ] encoding-opt max: 97.6% clean incremental-opt patched incremental: println-opt [ ] encoding max: 94.9% clean is ~ 20%, as is baseline incremental incremental cases are almost 100% [ ] coercions-opt max: 74.6% pretty universally bad, though incremental hurts worse [ ] coercions max: 66.6% pretty universally bad, though incremental hurts worse [ ] html5ever-opt max: 41.3% incremental [ ] inflate max: 40.4% universally bad, though incremental hurts worse [ ] regex-opt max: 4.7% patched incremental: byte frequencies-opt [ ] script-servo-opt max: 12.1% clean incremental-opt [ ] script-servo max: 11.6% clean incremental [ ] inflate-opt max: 11.6% incremental cases primarily
I'm going to start with ...
It would be good to dig into those use cases -- in particular, if you open them, we can see which of them are incremental use cases and which are not.
I just updated the tracking issue with that information. Most of them are incremental cases.
OK, for it's pretty clear: 58% of the execution time are spent in called from . Does that ring a bell, I haven't had time yet to really look at the code in question.
We might simply be encoding more constants now (that were previously encoded as HIR). I'll have to look at the exact logs (rustcmir::interpret::consteval=debug to just get the entry points). I'll check tomorrow morning
Ok. I found the issue. We don't seem to be loading constants from the cache. So the enormous regressions are from recomputing all constants, even if nothing changed in the code at all. That should be easy enough to fix
Only the incremental regressions were fixed. I'll investigate the others, too New perf data:
There have been a lot of perf optimizations for const eval over the last year. I think we're good now
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-61747.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

Discussion:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-61747.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

Discussion:
paniked when I tried to use GAT, I didn't know does not support it then. Anyway I think it is not supposed to panic. I have confirmed with version 1.39 on Windows, my PC version 1.36 on Linux. It said,
Seems a duplicate of , I did not noticed it when I was opening this issue, sorry. There is also a small difference that I did not turn on
cc &
This should be fixed in the next nightly

This is a toy example I made in order to later make tests which run for with . This is the error I get: Error notes: - compiler flags: I don't know if this kind of pattern is intended as part of the feature or in its future, but if not, I think it can be satisfied by using a procedural macro so that's probably alright. The point of the pattern, as I mentioned at the beginning of the post, is to be able to test a particular generic type's implementation up to an arbitrary range of numeric constants. While implementing another project to help test the feature, I stumbled upon the problem of wanting to test hundreds of different constants, but having no way of doing so with say, a loop over a range of constants. This is one way I thought of making it work. Am I making the right decisions here? How should I go about testing hundreds of constants? Thanks :)
Note: another example that also panics. I know, yes, expressions aren't yet supported as const parameters. But it has the same panic, which is WEIRD! When I wrote this one, I thought "okay maybe inside a statement, the compiler won't try things like because the case when is is already covered... and with exhaustiveness check it should know that N = 0 won't enter the second branch". But I must be wrong there, or otherwise how did it panic? Error:
Minified: I'm pretty sure that I saw this ICE before, but I can't find it ;/
This is just a result of having an expression () as a const generic argument. I don't actually think there's a canonical issue, though many of the issues are essentially the same. is the best tracking issue.
No longer ICEs on the latest nightly
Oh, the new output is interesting. It probably needs to be monomorphized so that the compiler detects the infinite recursion. And then we could also write one that doesn't have infinite recursion :3 In order to force an error, a test function should suffice right?
What do you mean?
I mean that I imagined it might detect that the function recurses infinitely onto itself. But I guess it reads it lazily, and lets monomorphization do the job of recursing the function? which would make a lot of sense to me.