jiebi/CodeConvo huggingface dataset:
Change:
// See rustc_resolve::late::lifetimes::LifetimeContext::add_missing_lifetime_specifiers_label let elided_lifetime_span = if generic_args.span.is_empty() { // If there are no brackets, use the identifier span. <del> path_span </del> <ins> // HACK: we use find_ancestor_inside to properly suggest elided spans in paths // originating from macros, since the segment's span might be from a macro arg. segment.ident.span.find_ancestor_inside(path_span).unwrap_or(path_span) </ins> } else if generic_args.is_empty() { // If there are brackets, but not generic arguments, then use the opening bracket generic_args.span.with_hi(generic_args.span.lo() + BytePos(1))

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 (which works correctly with rustc 1.57.0 stable): But with , I get: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also consider the following code, which creates an error message that could be more precise. I wouldn't call the following example a bug, but maybe these two issues are related: () Error output:
I think this is due to cc: let me see if I can fix this real quick.
claim
label +regression-from-stable-to-nightly +A-diagnostics
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
fn fold_ty(&mut self, t: Ty<'tcx>) -> Ty<'tcx> { if let ty::Opaque(def_id, substs) = t.kind { self.expand_opaque_ty(def_id, substs).unwrap_or(t) <del> } else { </del> <ins> } else if t.has_projections() { </ins> t.super_fold_with(self) <ins> } else { t </ins> } } } let mut visitor = OpaqueTypeExpander { seen_opaque_tys: FxHashSet::default(), <ins> expanded_cache: FxHashMap::default(), </ins> primary_def_id: def_id, found_recursion: false, tcx: self,

Discussion:
There is a crate inside of Fuchsia whose compile times increased from ~500ms to ~120s in the last month of Rust compiler updates. It hasn't been easy so far to provide a minimal example, but I will keep working at it. Some bisecting revealed that it actually consisted of two performance regressions, both affecting the time spent in : The first regression occurred in the rollup , and the second occurred sometime in the two weeks between changes ... There is heavy use of async/await in the code, and I've identified a couple places where taking out makes the compile finish right away. This makes me suspect for the first regression, but I'm not sure. I'll update the issue as I have more information.
Interestingly, removing from either of these places makes the compile much faster. If I leave both in, it's slow, but taking one or both out makes it faster. Maybe there's some kind of cycle being created when both are left in? In fact, switching on actually causes a cycle error to be reported when there wasn't one before. This is really weird to me, but it may be a red herring. Removing one or both of the calls (or calls to the methods that create the futures) doesn't resolve the cycle error, even though it resolves the slowdown. of the error, for completeness.
I don't have a lot more information to put here, except that the compile time seems to increase with the size of a particular call graph of async fns (it's not binary slow/fast, but different gradations of slow). This continues to make it hard to minimize. I did some profiling, and noticed a lot of time being spent collecting items in . Unfortunately I couldn't see what was calling that function. There was some speculation that it could be from (cc who suggested this). See for more details, and some flame graphs of the profiles I ran.
visited for T-compiler triage. Assigning P-high based on labels applied by niko as part of async-await triage. Removing nomination label too.
Change:
<ins> error: expected one of `)`, `,`, `.`, `?`, or an operator, found `é` --> $DIR/multibyte-char-use-seperator-issue-80134.rs:4:8 | LL |     (()é); |        ^ |        | |        expected one of `)`, `,`, `.`, `?`, or an operator |        help: missing `,` error: expected one of `)`, `,`, `.`, `?`, or an operator, found `氷` --> $DIR/multibyte-char-use-seperator-issue-80134.rs:8:8 | LL |     (()氷); |        -^ |        | |        expected one of `)`, `,`, `.`, `?`, or an operator |        help: missing `,` error[E0425]: cannot find value `é` in this scope --> $DIR/multibyte-char-use-seperator-issue-80134.rs:4:8 | LL |     (()é); |        ^ not found in this scope error[E0425]: cannot find value `氷` in this scope --> $DIR/multibyte-char-use-seperator-issue-80134.rs:8:8 | LL |     (()氷); |        ^^ not found in this scope error[E0658]: non-ascii idents are not fully supported --> $DIR/multibyte-char-use-seperator-issue-80134.rs:4:8 | LL |     (()é); |        ^ | = note: see issue #55467 <https://github.com/rust-lang/rust/issues/55467> for more information = help: add `#![feature(non_ascii_idents)]` to the crate attributes to enable error[E0658]: non-ascii idents are not fully supported --> $DIR/multibyte-char-use-seperator-issue-80134.rs:8:8 | LL |     (()氷); |        ^^ | = note: see issue #55467 <https://github.com/rust-lang/rust/issues/55467> for more information = help: add `#![feature(non_ascii_idents)]` to the crate attributes to enable error: aborting due to 6 previous errors Some errors have detailed explanations: E0425, E0658. For more information about an error, try `rustc --explain E0425`. </ins>

Discussion:
Was reported here : but still occurring. <!-- 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
Simpler repro: ()
I assume this repros for any non-ascii character, right? I tried with ü, ß, and , and I was able to repro.
Correct :) é was just the character my big fingers typed when I found that bug!
Assigning and removing as .20.E2.80.A6) in the prioritization working group.
This is a regression since modify labels: +regression-from-stable-to-stable
Change:
// Otherwise, we need to find the minimum remaining choice, if // any, and take that. debug!("choice_regions remaining are {:#?}", choice_regions); <del> let min = |r1: ty::RegionVid, r2: ty::RegionVid| -> Option<ty::RegionVid> { let r1_outlives_r2 = self.universal_region_relations.outlives(r1, r2); let r2_outlives_r1 = self.universal_region_relations.outlives(r2, r1); match (r1_outlives_r2, r2_outlives_r1) { (true, true) => Some(r1.min(r2)), (true, false) => Some(r2), (false, true) => Some(r1), (false, false) => None, } </del> <ins> let Some(&min_choice) = choice_regions.iter().find(|&r1| { choice_regions.iter().all(|&r2| { self.universal_region_relations.outlives(r2, *r1) }) }) else { debug!("no choice region outlived by all others"); return false; </ins> }; <del> let mut min_choice = choice_regions[0]; for &other_option in &choice_regions[1..] { debug!(?min_choice, ?other_option,); match min(min_choice, other_option) { Some(m) => min_choice = m, None => { debug!(?min_choice, ?other_option, "incomparable; no min choice",); return false; } } } </del> let min_choice_scc = self.constraint_sccs.scc(min_choice); debug!(?min_choice, ?min_choice_scc);

Discussion:
The following code should pass regardless of the declaration order of lifetimes: This is related to but it's different in that we do have a lower bound region, , but we fail to recognize that because , which is responsible for calculating from , assumes that the outlive relation is a total order, which is not true. Here is the graph of : ! So we need an efficient algorithm that works for partial order relations, but the one that comes to mind is . The perf may not be really important here but I'm curious to see the alternatives. label C-bug T-compiler A-borrow-checker E-mentor E-help-wanted <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Here is the code of concern The code should calculate the from a set of universal regions (). The relations are encoded in and are guaranteed to be transitive and reflexive. The relation graph may have cycles and can be sparse. The goal here is to find a unique minimum choice that is known to be outlived by all other regions. If none can be found, the function returns . Regions that have cycles between them are considered equivalent so we can pick either one of them as a unique choice. e.g. , we can pick either one of as a minimum choice.
Change:
let mut line_spans = Vec::with_capacity(args.templates.len()); let mut curarg = 0; <ins> let default_dialect = ecx.sess.inline_asm_dialect(); </ins> for template_expr in args.templates.into_iter() { if !template.is_empty() { template.push(ast::InlineAsmTemplatePiece::String("n".to_string()));

Discussion:
People used to gcc/clang inline assembly may try using the or directives directly in the assembly string, which can cause issues. Ideally, we should detect attempts to use those directives. Attempting to use should generate an error stating that that's the default. Attempting to use should generate an error and point to the option, ideally with a rustfix-applicable suggestion. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is anyone currently working on this? I would like to do it if not.
Not to my knowledge, no.
claim
Change:
name: Name, origin: BTreeSet<Span>, target: BTreeSet<Span>, <ins> could_be_path: bool </ins> } impl PartialOrd for BindingError {

Discussion:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.

sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.
Change:
); } } else { <del> let guar = match region.opt_param_def_id(self.tcx, self.tcx.parent(self.def_id)) { </del> <ins> let guar = match region.opt_param_def_id(self.tcx, self.impl_m_def_id) { </ins> Some(def_id) => { let return_span = if let ty::Alias(ty::Opaque, opaque_ty) = self.ty.kind() { self.tcx.def_span(opaque_ty.def_id)

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected lifetime parameter, but found another generic parameter', 'error: internal compiler error: expected lifetime parameter, but found another generic parameter' 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: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of --
cc
Change:
} } <del> impl NoClose { fn new(handle: c::HANDLE) -> NoClose { NoClose(Some(Handle::new(handle))) } fn get(&self) -> &Handle { self.0.as_ref().unwrap() } } impl Drop for NoClose { fn drop(&mut self) { self.0.take().unwrap().into_raw(); } } </del> impl Output { <del> pub fn handle(&self) -> &Handle { let nc = match *self { Output::Console(ref c) => c, Output::Pipe(ref c) => c, }; nc.0.as_ref().unwrap() </del> <ins> pub fn handle(&self) -> c::HANDLE { match *self { Output::Console(c) => c, Output::Pipe(c) => c, } </ins> } }

Discussion:
Over time the value of may change (e.g. see ) and we should likely reload the value over time instead of caching the return value to catch cases like this.
There's very little value in caching the result. takes 3 nanoseconds for me according to a quick bench.
Change:
let idx = self.idx_vec.push(borrow); self.location_map.insert(location, idx); <del> // This assert is a good sanity check until more general 2-phase borrow // support is introduced. See NOTE on the activation_map field for more assert!(!self.activation_map.contains_key(&activate_location), "More than one activation introduced at the same location."); self.activation_map.insert(activate_location, idx); </del> <ins> insert(&mut self.activation_map, &activate_location, idx); </ins> insert(&mut self.assigned_map, assigned_place, idx); insert(&mut self.region_map, &region, idx); if let Some(local) = root_local(borrowed_place) {

Discussion:
This program : See also , which I believe to be relevant. I'm refactoring some of this code, trying to explore the new NLL approach, so I will probably wind up fixing this. But obviously we should have this as a test! cc
Is this similar to this ICE?
Change:
<ins> // check-pass #![allow(dead_code)] trait Structure<E>: Sized where E: Encoding { type RefTarget: ?Sized; type FfiPtr; unsafe fn borrow_from_ffi_ptr<'a>(ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget>; } enum Slice {} impl<E> Structure<E> for Slice where E: Encoding { type RefTarget = [E::Unit]; type FfiPtr = (*const E::FfiUnit, usize); unsafe fn borrow_from_ffi_ptr<'a>(_ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget> { panic!() } } trait Encoding { type Unit: Unit; type FfiUnit; } trait Unit {} enum Utf16 {} impl Encoding for Utf16 { type Unit = Utf16Unit; type FfiUnit = u16; } struct Utf16Unit(pub u16); impl Unit for Utf16Unit {} type SUtf16Str = SeStr<Slice, Utf16>; struct SeStr<S, E> where S: Structure<E>, E: Encoding { _data: S::RefTarget, } impl<S, E> SeStr<S, E> where S: Structure<E>, E: Encoding { pub unsafe fn from_ptr<'a>(_ptr: S::FfiPtr) -> Option<&'a Self> { panic!() } } fn main() { const TEXT_U16: &'static [u16] = &[]; let _ = unsafe { SUtf16Str::from_ptr((TEXT_U16.as_ptr(), TEXT_U16.len())).unwrap() }; } </ins>

Discussion:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest
Change:
<ins> // check-pass #![allow(dead_code)] trait Structure<E>: Sized where E: Encoding { type RefTarget: ?Sized; type FfiPtr; unsafe fn borrow_from_ffi_ptr<'a>(ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget>; } enum Slice {} impl<E> Structure<E> for Slice where E: Encoding { type RefTarget = [E::Unit]; type FfiPtr = (*const E::FfiUnit, usize); unsafe fn borrow_from_ffi_ptr<'a>(_ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget> { panic!() } } trait Encoding { type Unit: Unit; type FfiUnit; } trait Unit {} enum Utf16 {} impl Encoding for Utf16 { type Unit = Utf16Unit; type FfiUnit = u16; } struct Utf16Unit(pub u16); impl Unit for Utf16Unit {} type SUtf16Str = SeStr<Slice, Utf16>; struct SeStr<S, E> where S: Structure<E>, E: Encoding { _data: S::RefTarget, } impl<S, E> SeStr<S, E> where S: Structure<E>, E: Encoding { pub unsafe fn from_ptr<'a>(_ptr: S::FfiPtr) -> Option<&'a Self> { panic!() } } fn main() { const TEXT_U16: &'static [u16] = &[]; let _ = unsafe { SUtf16Str::from_ptr((TEXT_U16.as_ptr(), TEXT_U16.len())).unwrap() }; } </ins>

Discussion:
While minimizing I stumbled upon another ICE () Errors:
modify labels: I-ICE A-closures A-impl-trait C-bug F-typealiasimpl_trait T-compiler
The ICE doesn't appear on the latest nightly
Change:
<ins> error[E0697]: closures cannot be static --> $DIR/issue-52432.rs:4:12 | LL |     [(); &(static |x| {}) as *const _ as usize]; |            ^^^^^^^^^^ error[E0697]: closures cannot be static --> $DIR/issue-52432.rs:7:12 | LL |     [(); &(static || {}) as *const _ as usize]; |            ^^^^^^^^^ error[E0282]: type annotations needed --> $DIR/issue-52432.rs:4:20 | LL |     [(); &(static |x| {}) as *const _ as usize]; |                    ^ consider giving this closure parameter a type error[E0080]: evaluation of constant value failed --> $DIR/issue-52432.rs:7:10 | LL |     [(); &(static || {}) as *const _ as usize]; |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "pointer-to-integer cast" needs an rfc before being allowed inside constants error: aborting due to 4 previous errors Some errors have detailed explanations: E0080, E0282, E0697. For more information about an error, try `rustc --explain E0080`. </ins>

Discussion:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest
Change:
<ins> error[E0697]: closures cannot be static --> $DIR/issue-52432.rs:4:12 | LL |     [(); &(static |x| {}) as *const _ as usize]; |            ^^^^^^^^^^ error[E0697]: closures cannot be static --> $DIR/issue-52432.rs:7:12 | LL |     [(); &(static || {}) as *const _ as usize]; |            ^^^^^^^^^ error[E0282]: type annotations needed --> $DIR/issue-52432.rs:4:20 | LL |     [(); &(static |x| {}) as *const _ as usize]; |                    ^ consider giving this closure parameter a type error[E0080]: evaluation of constant value failed --> $DIR/issue-52432.rs:7:10 | LL |     [(); &(static || {}) as *const _ as usize]; |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "pointer-to-integer cast" needs an rfc before being allowed inside constants error: aborting due to 4 previous errors Some errors have detailed explanations: E0080, E0282, E0697. For more information about an error, try `rustc --explain E0080`. </ins>

Discussion:
While minimizing I stumbled upon another ICE () Errors:
modify labels: I-ICE A-closures A-impl-trait C-bug F-typealiasimpl_trait T-compiler
The ICE doesn't appear on the latest nightly
Change:
use std::hash::Hash; use super::{ <del> err_ub, format_interp_error, machine::AllocMap, throw_ub, AllocId, CheckInAllocMsg, </del> <ins> err_ub, format_interp_error, machine::AllocMap, throw_ub, AllocId, AllocKind, CheckInAllocMsg, </ins> GlobalAlloc, ImmTy, Immediate, InterpCx, InterpResult, MPlaceTy, Machine, MemPlaceMeta, OpTy, Pointer, Projectable, Scalar, ValueVisitor, };

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not find allocation for alloc3', 'error: internal compiler error: could not find allocation for alloc3' 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: [evalstaticinitializer] evaluating initializer of static [analysis] running analysis passes on this crate -- label +F-extern_types
Regression in nightly-2024-05-23 cc :thinking:
Anyway it doesn't seem to affect the test.
This is not a recent regression, here's a reproducer on stable:
But why?^^ lol XD its just side effect of the fuzzing I guess :D
Change:
let path_map = &move_data.path_map; let rev_lookup = &move_data.rev_lookup; <del> debug!("stmt {:?} at loc {:?} moves out of move_indexes {:?}", stmt, location, &loc_map[location]); for move_index in &loc_map[location] { // Every path deinitialized by a *particular move* // has corresponding bit, "gen'ed" (i.e. set) // here, in dataflow vector zero_to_one(sets.gen_set.words_mut(), *move_index); </del> <ins> match stmt.kind { // this analysis only tries to find moves explicitly // written by the user, so we ignore the move-outs // created by `StorageDead` and at the beginning // of a function. mir::StatementKind::StorageDead(_) => {} _ => { debug!("stmt {:?} at loc {:?} moves out of move_indexes {:?}", stmt, location, &loc_map[location]); for move_index in &loc_map[location] { // Every path deinitialized by a *particular move* // has corresponding bit, "gen'ed" (i.e. set) // here, in dataflow vector zero_to_one(sets.gen_set.words_mut(), *move_index); } } </ins> } let bits_per_block = self.bits_per_block(); match stmt.kind { mir::StatementKind::SetDiscriminant { .. } => {

Discussion:
MIR borrowck considers variables still initialized after their storage ends, so if an immutable variable is defined and used in a loop, this causes an error. e.g.: Which causes:
working on it