jiebi/CodeConvo huggingface dataset:
Change:
let all_traits = Vec::from_iter(self.resolver.cstore().traits_in_crate_untracked(cnum)); let all_trait_impls = Vec::from_iter(self.resolver.cstore().trait_impls_in_crate_untracked(cnum)); <ins> let all_inherent_impls = Vec::from_iter(self.resolver.cstore().inherent_impls_in_crate_untracked(cnum)); </ins> // Querying traits in scope is expensive so we try to prune the impl and traits lists // using privacy, private traits and impls from other crates are never documented in

Discussion:
Running on nightly causes an ICE. Judging by my for PRs this broken between 2 and 4 days ago (26th-28th Jan). See attached minified project: . Essentially, this is: <details<summary<strongBacktrace</strong</summary<p</p</details
I see the same on Docs build fine with latest stable (1.58.1), but I get the same error with
This is probably a duplicate of , right? The fix for that () isn't in yesterday's (2022-01-29) nightly yet, but should be in today's.
I get the same error with , which does include .
works for me on aarch64-apple-darwin, but not on
There are definitely three crates still hitting this ICE on (at least based on message, and backtrace in 2 cases, but I couldn't reproduce on when testing locally) in
You can use () in your code to figure out what change caused this regression.
Not so surprisingly bisection reveals as the cause.
I'm not sure if this is helpful, but this is the stack I get when attempting to run rustdoc with nightly (which is the most recent nightly available on macOS). I also get the same build failure in CI with . This error comes from building the docs on
Fixed in
Assigning same priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
It seems this issue has regressed recently? Hitting the same ICE on . <details<summary<strongBacktrace</strong</summary<p</p</details
The recent regression should be fixed by , most likely.
Change:
} } <del> // Mutability check. </del> <ins> // Dangling and Mutability check. let (size, _align, alloc_kind) = self.ecx.get_alloc_info(alloc_id); if alloc_kind == AllocKind::Dead { // This can happen for zero-sized references. We can't have *any* references to non-existing // allocations though, interning rejects them all as the rest of rustc isn't happy with them... // so we throw an error, even though this isn't really UB. // A potential future alternative would be to resurrect this as a zero-sized allocation // (which codegen will then compile to an aligned dummy pointer anyway). throw_validation_failure!(self.path, DanglingPtrUseAfterFree { ptr_kind }); } </ins> // If this allocation has size zero, there is no actual mutability here. <del> let (size, _align, _alloc_kind) = self.ecx.get_alloc_info(alloc_id); </del> if size != Size::ZERO { let alloc_actual_mutbl = mutability(self.ecx, alloc_id); // Mutable pointer to immutable memory is no good.

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:
// if a Sync generator contains an &'α T, we need to check whether &'α T: Sync), // so knowledge of the exact relationships between them isn't particularly important. <del> debug!("types in generator {:?}, span = {:?}", type_list, body.value.span); </del> <ins> debug!("types in generator {:?}, span = {:?}", types, body.value.span); </ins> // Replace all regions inside the generator interior with late bound regions // Note that each region slot in the types gets a new fresh late bound region, // which means that none of the regions inside relate to any other, even if // typeck had previously found constraints that would cause them to be related. let mut counter = 0; <del> let type_list = fcx.tcx.fold_regions(&type_list, &mut false, |_, current_depth| { </del> <ins> let types = fcx.tcx.fold_regions(&types, &mut false, |_, current_depth| { </ins> counter += 1; fcx.tcx.mk_region(ty::ReLateBound(current_depth, ty::BrAnon(counter))) }); <ins> // Store the generator types and spans into the tables for this generator. let interior_types = types.iter().map(|t| t.0.clone()).collect::<Vec<_>>(); visitor.fcx.inh.tables.borrow_mut().generator_interior_types = interior_types; // Extract type components let type_list = fcx.tcx.mk_type_list(types.into_iter().map(|t| (t.0).ty)); </ins> let witness = fcx.tcx.mk_generator_witness(ty::Binder::bind(type_list)); debug!("types in generator after region replacement {:?}, span = {:?}",

Discussion:
Hyper fails to compile on Rust master () <details</details
fyi
I also get this with on futures-rs <details</details
getting this while trying to compile rust itself(): <details</details
Confirming bisection range is
guessing it's PR attempting rust compilation with reverted like so: <details</detailsthis might take a while...
It's not it, surprisingly enough(for me). (manually)Reverting that PR fails the same. (that is, applied this on top of rust commit ) <details</details<details</details
? This PR adds to typeck-table which is stable-hashed, and the hyper ICE is happening on by querying that table, which looks relevant.
I've reversed-applied the patch from (aka reverted PR ) on top of rust like this , and the results are(74mins later, at least): it passed!(failed later, on clippy_lints, but that's unrelated) So that's the problematic PR, thanks Since rust got updated compared to my previous try, I'll re-apply this PR on top of what already worked just now to see if it indeed fails with it! <sWill post new comment with the update.</sConfirmed the ICE is back with that PR, using 's test-case: <details</details
Minimized test-case:
Thanks self-assigning to look into this (since I caused it with ) - if anyone else wants to look into fixing also, please feel free.
I have a WIP fix:
Change:
#[cfg(any(target_os = "macos", target_os = "ios"))] mod inner { use crate::fmt; <del> use crate::sync::Once; </del> <ins> use crate::mem; use crate::sync::atomic::{AtomicUsize, Ordering::SeqCst}; </ins> use crate::sys::cvt; use crate::sys_common::mul_div_u64; use crate::time::Duration;

Discussion:
I was trying to troubleshoot this issue: and eventually we figured out that on my machine parktimeout wasn't waking up. I wrote this simple test code which demonstrates the issue: Most of the time it will only print this: Every once in a while it will finish normally. This behavior happens on stable and nightly and I tried a handfull of stable versions all the way back to 1.12 and they all got stuck. Windows (both msvc and gnu appear to never get stuck (at least I couldn't reproduce the issue)). I was able to duplicate this an another mac as well (both running 10.14) If only a single thread is started (or the park happens on the main thread) then I can't reproduce. I'm on 10.14; uname:
This definitely seems broken. Here's dtruss output:
It's a deadlock on the ONCE here:
As a workaround, everything should work fine as long as you construct an at least once in your process before parking.
Doesn't seem to help :(
Oh right sorry, you actually have to subtract two Instants to force that Once to complete. If you instead do at the start of main, it prevents the deadlock.
Works perfectly now! Thanks!
Change:
<ins> error[E0407]: method `foo` is not a member of trait `Foo` --> $DIR/ice-mir-const-qualif-125837.rs:10:5 | LL | /     fn foo<'a>(&'a self) -> impl Debug { LL | | LL | |         const { return } LL | | LL | |     } | |_____^ not a member of trait `Foo` error[E0107]: missing generics for trait `Foo` --> $DIR/ice-mir-const-qualif-125837.rs:8:30 | LL | impl<Item, D: Debug + Clone> Foo for D { |                              ^^^ expected 1 generic argument | note: trait defined here, with 1 generic parameter: `Item` --> $DIR/ice-mir-const-qualif-125837.rs:6:7 | LL | trait Foo<Item> {} |       ^^^ ---- help: add missing generic argument | LL | impl<Item, D: Debug + Clone> Foo<Item> for D { |                                 ++++++ error[E0572]: return statement outside of function body --> $DIR/ice-mir-const-qualif-125837.rs:12:17 | LL | /     fn foo<'a>(&'a self) -> impl Debug { LL | | LL | |         const { return } | |               --^^^^^^-- the return is part of this body... LL | | LL | |     } | |_____- ...not the enclosing function body error: aborting due to 3 previous errors Some errors have detailed explanations: E0107, E0407, E0572. For more information about an error, try `rustc --explain E0107`. </ins>

Discussion:
Similar to but different query stack <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' 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: [mirbuilt] building MIR for [mirconstqualif] const checking --
ICE introduced in . No longer ICEs after , which was a partial revert of
Change:
self.set_debug_loc(bx, var.source_info); let base = Self::spill_operand_to_stack(operand, Some(var.name.to_string()), bx); <ins> bx.clear_dbg_loc(); </ins> bx.dbg_var_addr( dbg_var,

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: Setting a breakpoint on in rust-gdb results in gdb stopping before 's stack slot is initialized, and gdb dereferences it to print wrong values based on : Note the incorrect different values of as I step past initialization. The breakpoint should trigger just after that , not before it. The other functions in that program indeed do it correctly. Oddly, it seems like the operator is necessary for my repro, though maybe that has something to do with the hidden var. (Note that vs is necessary to actually avoid accidental correct values of due to stack reuse, so the other functions can't print wrong as written. But I'm just looking at where the breakpoint hits in disassembly.) Here's relevant llvm-dwarfdump from this binary, with a pointing at at the () rather than the : This looks pretty related to and Like , the repro hits on 1.71 but not 1.70. I'm filing separately because, unlike it, disabling SingleUseConsts doesn't seem to fix the breakpoint. I'm not 100% sure I'm disabling it right - you can see my command above. <!-- 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<summaryBacktrace</summary<p</p</details
I'm not familiar with github's notification rules, so pinging
Thanks for the tag, I wouldn't have seen this otherwise. From , we can see that the "prologue end" marker that tells the debugger where to stop is indeed placed on the mov I suspect this is due to the desugaring of the ? operator since the column number provided is 29.
label +A-debuginfo
Sure enough, ConstDebugInfo is in there.
I guess you probably saw, but does suggest that the bisect is somehow misleading.
Yes, getting the values wrong at function entry is especially bad because it messes up conditional breakpoints.
Disabling the pass doesn't do anything here because the is created by when it removes . Otherwise this is identical to .

The easiest way to fix this would be for DILocation to carry a "this is not a statement" flag that overrides LLVM's usual line based inference of statement markers. I'll run it by the LLVM folks and see what they say.
Actually, in this particular case, because the const is a ZST I think we can do better today without LLVM changes.
Thanks for reporting this. The linked PR will fix this particular degenerate case.
Change:
vals_size, min_align_of::<V>()); unsafe { <del> deallocate(self.hashes.0 as *mut u8, size, align); </del> <ins> deallocate(self.hashes as *mut u8, size, align); </ins> // Remember how everything was allocated out of one buffer // during initialization? We only need one call to free here. }

Discussion:
This compiles, despite Rc<T: !Send. I'm guessing this is because RawTable only uses K and V with marker::CovariantType, and I guess that isn't enough for the negative-impl to propagate. I haven't checked which other collections might be unsafe.
It appears that this also isn't specifically related to trait bounds: cc
Ah, yeah. RawTable contains only a , which is of course always Send/Sync. It should presumably just contain a plain and impl Send/Sync conditionally?
Or we need a more rich marker type.
may be a good replacement for the current system as it could contain a marker of and for example. For now though a manual impl of and will probably be required. Should other collections with an unsafe representation also be audited?
I can say confidently this is the only problem case in collections. It's the only collection that uses basically a pointer.
ok cool, good to know!
Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // ignore-pretty pretty-printing is unhygienic #![feature(decl_macro)] #![allow(unused)] mod foo { pub macro m($s:tt, $i:tt) { $s.$i } } mod bar { struct S(i32); fn f() { let s = S(0); ::foo::m!(s, 0); } } fn main() {} </ins>

Discussion:
If a procedural macro generates an access to a named struct field like then the may be either defsite or callsite and it works either way. But if accessing an unnamed tuple struct field like then it only works if is call_site. I believe it should work either way in either case.
Sorry for the delay! Fixed in .
Change:
" init                                          Set up .cargo <del> install [--test] [source/]package-name        Install by name install [--test] uuid:[source/]package-uuid   Install by uuid </del> <ins> install [options] [source/]package-name       Install by name install [options] uuid:[source/]package-uuid  Install by uuid </ins> list [source]                                 List packages search <name | '*'> [tags...]                 Search packages sync                                          Sync all sources

Discussion:
There's some code for this in cargo now, but it doesn't quite do the right thing. See .
Also worth considering the difference between sysroot and the install prefix - they are not the same. For instance, I never install cargo, always running it out of the build directory, in which case the build directory is sysroot.
I think this is resolved.
Change:
<ins> // run-rustfix fn main() { let _x = 42; //~ HELP let _y = x; //~ ERROR } </ins>

Discussion:
Variables can be marked as unused by prepending with an underscore. If at some point such a variable is used again, the compiler suggests to name the use , even though every single time I have encountered this, what I wanted is to change the definition of to . () Errors:
I feel we should have a counterpart to the unused lint that checks for variables that are used but use the unused bar convention. That wouldn't be useful for the case presented here where you're using an unused bar for the first time, but seems like a reasonable addition.
Such a lint is problematic within macros or other compiler-expanded code, since it's a common pattern to work around not knowing if there are any uses by naming the variables appropriately (for an example look at the loop lowering code)
I agree but I'm pretty sure that most lints should ignore code with spans in macro context already.
Hi, I'd like to work on this!
sorry for not responding earlier. I only have very broad instructions right now, but don't hesitate to ask here or on the stream on zulip if you need more help. the place where the diagnostic "a local variable with a similar name exists" is emitted note that the "local variable" part may be a placeholder and the rest of the string might be broken across multiple lines if that place has more info than just the name of the local variable not, add a to whatever datastructure holds the name I'm not sure how the name is obtained right now, but there should be a way to get at the there, too. E.g. if the name is an , then it has a field. emitting the "similar name" diagnostic, first check whether the suggested name starts with an underscore, but the name used in the code does not that chek fails, keep the old message , emit the suggestion not on the span that it is currently emitted on, but on the definition span (and change the suggestion to remove the underscore)
Hi I've already done most of that :) I think I'll have a working PR next week.
I can work on this if you guys are caught up with something else :)
sure. Just once you start working on it. Maybe you can even get the WIP branch from fork
Change:
} _ => return err, }, <del> [.., field] => ( match pat.kind { PatKind::Struct(_, [_, ..], _) => ", ", _ => "", }, "", field.span.shrink_to_hi(), ), </del> <ins> [.., field] => { // if last field has a trailing comma, use the comma // as the span to avoid trailing comma in ultimate // suggestion (Issue #78511) let tail = field.span.shrink_to_hi().until(pat.span.shrink_to_hi()); let tail_through_comma = self.tcx.sess.source_map().span_through_char(tail, ','); let sp = if tail_through_comma == tail { field.span.shrink_to_hi() } else { tail_through_comma }; ( match pat.kind { PatKind::Struct(_, [_, ..], _) => ", ", _ => "", }, "", sp, ) } </ins> }; err.span_suggestion( sp,

Discussion:
I tried this code: I expected to see this happen: A suggestion to change to Instead, this happened: A suggestion to change to (note the extra comma!) With the comma at the end, I get a parser error and a suggestion to remove the comma. Nightly on playground: 1.49.0-nightly (2020-10-27 )
modify labels: +A-diagnostics
Change:
if !ty_is_partial_eq { // span_fatal avoids ICE from resolution of non-existent method (rare case). <del> self.tcx().sess.span_fatal(self.span, &make_msg()); </del> <ins> self.tcx().sess.span_fatal(self.span, &msg); </ins> } else if mir_structural_match_violation { self.tcx().struct_span_lint_hir( lint::builtin::INDIRECT_STRUCTURAL_MATCH, self.id, self.span, <del> |lint| lint.build(&make_msg()).emit(), </del> <ins> |lint| lint.build(&msg).emit(), </ins> ); } else { debug!(

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. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.
Change:
if !ty_is_partial_eq { // span_fatal avoids ICE from resolution of non-existent method (rare case). <del> self.tcx().sess.span_fatal(self.span, &make_msg()); </del> <ins> self.tcx().sess.span_fatal(self.span, &msg); </ins> } else if mir_structural_match_violation { self.tcx().struct_span_lint_hir( lint::builtin::INDIRECT_STRUCTURAL_MATCH, self.id, self.span, <del> |lint| lint.build(&make_msg()).emit(), </del> <ins> |lint| lint.build(&msg).emit(), </ins> ); } else { debug!(

Discussion:
Pretty straightforward. The idea is to plug logic into a template. This seems like something that should/could work. Playground link: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
"smaller": Error:
claim
release-assignment is not structural match so this should not compile. We probably shouldn't ICE here though :laughing: cc
It shouldn't be, but it currently is. To fix it you need to change , .
Change:
cx.struct_span_lint(UNSAFE_CODE, span, decorate); } <ins> fn report_overriden_symbol_name(&self, cx: &EarlyContext<'_>, span: Span, msg: &str) { self.report_unsafe(cx, span, |lint| { lint.build(msg) .note( "the linker's behavior with multiple libraries exporting duplicate symbol  names is undefined and Rust cannot provide guarantees when you manually  override them", ) .emit(); }) } </ins> } impl EarlyLintPass for UnsafeCode {

Discussion:
Given that there should be a lint that is capable of detecting it (there was a suggestion that should also detect it, but it might make sense to be able to lint it individually too).
So maybe should be a lint group, and include this new lint? I am suggesting that because I think should suffice to trigger the new lint.
I've got the basic lint working now. do you think it's worth adding it as a separate lint, renaming to something else (which I can't think of a name for), and adding them both as lints in an group; or better to just integrate it into the current lint?
I'll defer to for that :D
I am partial towards having a hard error when encountering multiple functions with the same name in a given workspace, . Adding this to might be problematic in the wild. Let's make a PR that rolls it into and see the behavior in the wild with a crater run, but if it causes too much fallout, lets make it an independent lint.
There's other ways of using which create UB than just overriding within a workspace, e.g. the example in While adding a hard error for cases that can be detected would be nice, I don't think it's possible in general.
Removing I-prioritize since this is already tracked at
Is there a tracking issue for additional lints like this to similar "unsafe attributes"? I think that'd be great!
not that I know of but you could open one :)
Done