jiebi/CodeConvo huggingface dataset:
Change:
Excluded(&n) => n, Unbounded => len, }; <del> assert!(start <= end); assert!(end <= len); </del> <ins> #[cold] #[inline(never)] fn start_assert_failed(start: usize, end: usize) -> ! { panic!("start drain index (is {}) should be <= end drain index (is {})", start, end); } #[cold] #[inline(never)] fn end_assert_failed(end: usize, len: usize) -> ! { panic!("end drain index (is {}) should be <= len (is {})", end, len); } if !(start <= end) { start_assert_failed(start, end); } if !(end <= len) { end_assert_failed(end, len); } </ins> unsafe { // set self.vec length's to start, to be safe in case Drain is leaked

Discussion:
I've spotted, that panic message could've provided details on what values led to this panic, instead of mentioning condition only. Generally speaking this and some other s in Vec could've been more detailed. If it's okay to step in, I'd like to offer my help. In case of I'd suggest calling this instead I find this more informative than Candidates for improval: aforementioned : : : :
Does triaging mean a green light for this suggestion?
No, I just apply the relevant labels. :)
Though this is a small change with little time required to fix, so I'd just make the PR if I were you. :)
Note: uses the same kind of assertion in (as the old check had aliasing issues). Depending on which PR lands first, we should make sure it gets the same panic message as the others.
I think it makes sense to follow the message, that is being currently printed, when trying to access element out of bounds via . Current message template is . I followed this idiom to keep it consistent.
Change:
use rustc_ast as ast; use rustc_data_structures::fx::FxHashMap; use rustc_data_structures::sync; <del> use rustc_errors::{ add_elided_lifetime_in_path_suggestion, struct_span_err, Applicability, SuggestionStyle, }; </del> <ins> use rustc_errors::{struct_span_err, Applicability, SuggestionStyle}; </ins> use rustc_hir as hir; use rustc_hir::def::Res; use rustc_hir::def_id::{CrateNum, DefId};

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
This bisects to &mdash; regressed nightly: nightly-2021-12-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
There was an issue with similar ICE that has been fixed recently Does this problem still repro with latest nightly ?
Yes this one still reproduces as of that nightly, which contains .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
let handler = self.0.handler; <del> // We need to use `ptr::read` because `DiagnosticBuilder` implements `Drop`. let diagnostic; unsafe { diagnostic = std::ptr::read(&self.0.diagnostic); std::mem::forget(self); }; </del> <ins> // We must use `Level::Cancelled` for `dummy` to avoid an ICE about an // unused diagnostic. let dummy = Diagnostic::new(Level::Cancelled, ""); let diagnostic = std::mem::replace(&mut self.0.diagnostic, dummy); </ins> // Logging here is useful to help track down where in logs an error was // actually emitted. debug!("buffer: diagnostic={:?}", diagnostic);

Discussion:
This code leaks the at : The leak was introduced in . cc
We could avoid the leak and the by doing or if we're concerned about performance here, we could maybe do something with .
Thanks for the report, I will measure the perf effects of the different alternatives. I'd like to know how you found this -- code inspection? Some kind of tool?
I found it while running and noticing that I kept running out of memory. I turned on and this popped out.
Another alternative could be to call to swap in a dummy diagnostic, instead of cloning the existing one.
Below is an example compiler input that triggers the leak:
Simpler example that triggers the leak: just a single closing brace
Change:
#![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")] #![feature(box_patterns)] <ins> #![feature(drain_filter)] </ins> #![feature(bool_to_option)] #![feature(crate_visibility_modifier)] #![feature(format_args_capture)]

Discussion:
rustc often offers a help to import something from std and core: Perhaps in such situations rustc could use an heuristic to suggest only one of the two imports.
cc feels like we should at least show first here?
This is quite useful in situations like the rust playground because there sometimes there are many different sources for a function, and sometimes the std one (that's most times the one you really want) gets elided in the "others" sources.
We already have a couple of hacks for these kind of suggestions, so I'd be fine with just modifying the code here to push any suggestion that starts with to the end of the list, or at the very least, after . As pointed above it might make sense to bias the sort to always put first. We could also consider removing all references to , but that makes me uneasy.
The regression test (), when run on the playground, does seem to have regressed between beta 1.57.0 and nightly 1.58.0, which is weird because it's a test, so it shouldn't have changed. Maybe it only regressed when there are external dependencies?
Change:
<ins> // opyright 2013 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. #[path = "../compile-fail"] mod foo; //~ ERROR: illegal operation on a directory fn main() {} </ins>

Discussion:
Having a generic seems to be necessary to exhibit the bug. (Caused .)
Reproduced with . Nominating.
cc me
declining; just-a-bug
cc me; possibly addressed by patch to
This has been fixed, adding a test for it soon.

Nominating well defined.
This seems to be fixed.
Not quite: If you put on the inner module, it works. I think this is actually working as intended: the 'pub' on the item being re-exported is itself the indication of whether it can be seen from outside. Curiously, you can't use it locally (with no anywhere in the file) either. This feels not entirely well defined? Or else I'm not well informed enough to address it. Leaving open until we have Patrick around for subsequent triage.
My two cents: makes sense that a 'd item must be , since that means you don't have to search for a pub use. seems like ought to work though.
accepted for well-defined milestone
This is working now. I think my extraction of privacy from resolve has fixed this. Removing all tags and flagging as needstest.
Change:
<ins> // opyright 2013 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. #[path = "../compile-fail"] mod foo; //~ ERROR: illegal operation on a directory fn main() {} </ins>

Discussion:
With the following test code: You get an ICE:
Looks quite similar to , which is probably .
After updating for removal of and feature-gating of macros, I don't get ICE any more.
Almost certainly fixed by

This code: Causes the ICE cc
Also a similar, but different error:
I've also confirmed that if everything is defined in the same crate, it all compiles just fine.
This may be related to , although it's a different error message so I'm not sure of it.
This is not related to
I just ran into this myself. One interesting thing I found is that the error happens due to the empty variant. This compiles fine for me:
Appears to be fixed now, flagging as needstest.

To replicate: (Original report follows:) I had code like this: This causes rustc to spin forever. Here's the interesting part of the stack trace:
In my attempt to replicate the bug (on a Mac OS machine), this appears to ICE now rather than hang.
(The fact that it ICE's now rather than diverges is probably thanks to )
Reproduced with
This was fixed at some point, the error message is now: which is exactly what one would expect! Flagging as needstest.
Change:
<ins> // Copyright 2015 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. // compile-flags: --test #![deny(unstable)] #[test] fn foo() {} </ins>

Discussion:
With a file like: And then running , these warnings are inserted: cc
I believe was working on this.
Nominating though, when we deny warnings in beta I've gotta be able to test my code still!
I've been using , and this blocks me from testing. For now, I have to comment out that line...
Change:
unsafe { let llty = llvm::LLVMTypeOf(v); <ins> if contains_null(sym.as_slice()) { ccx.sess().fatal( format!("Illegal null byte in export_name value: `{}`", sym).as_slice()); } </ins> let g = sym.as_slice().with_c_str(|buf| { llvm::LLVMAddGlobal(ccx.llmod(), llty, buf) });

Discussion:
Both the exportname and linksection attributes will produce an ICE if '0' is contained within the string. Input Output and Bakctrace Version
Fascinating find! I'm curious about what lead you to it. Is there a need to put null in these values?
I had typed rather than . It was an accidental discovery, I'm not aware of any need for a null character here.
I marked this as easy since fixing this is probably just a matter of going to that exact code and emitting a proper error. Good starter bug.
This is actually caused by CStrings failing the task if they have an interior null. . Adding an error would fix this particular issue, but it wouldn't fix the underlying issue, so maybe a different course of action would be better. On a side note, what is the proper way to add an error to the compiler? ? ? I couldn't find any documentation on it.
What is the underlying issue? That we should always throw an error if a has an interior null character? Or that we should allow 's to have null characters?
The underlying issue was that the checked versions of tocstring and withcstr crash on interior nulls. Doing an extra interior null check before calling them in this case doesn't help with this problem in other cases, and failing the task seems unnecessary, especially for the checked version. Perhaps the checked version could return an Option, and the unchecked would keep its current behavior. Edit: Alternately, a tocstropt function could be and used where necessary.
Is anyone working on this? I'll take a crack at it this week if not.
I am. I a withcstr_opt function (that had to wait on ), and am putting the finishing touches on the error messages.
Change:
<ins> #![crate_type = "lib"] struct S<T = (), 'a>(&'a T); //~^ ERROR lifetime parameters must be declared prior to type parameters </ins>

Discussion:
results in: when it should be: This should be easy to fix: just replace in the following line with an appropriate format string. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
For the record, it's not quite this simple, as doing so results in incorrect output when the parameter also has bounds. For example, it would render as because bounds are printed after the
Change:
<ins> // check-pass // compile-flags: --crate-type=lib #[allow(private_bounds)] pub trait Foo: FooImpl {} trait FooImpl {} </ins>

Discussion:
I tried this code: I expected to see this happen: The lint is allowed. Instead, this happened: The lint still triggers. (Applying to the entire module works). (I'm assuming that this is unintentional, thus reporting as a "bug". If this behavior is intentional, consider this a feature request to change it). Latest playground nightly:
The problem here is that the lint is associated with the private item, not the item which names it in its bounds:
cc
Change:
<ins> error: cannot find macro `foo` in this scope --> $DIR/path-attr-in-const-block.rs:6:19 | LL |         #![path = foo!()] |                   ^^^ error: aborting due to 1 previous error </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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
bisects to cc
That's a revert, the issue probably exists much longer
ah :+1: when I start the bisection at a later point, this goes down to Regression in nightly-2023-11-29 probably ?
Jup, that looks like it
Change:
crt_static_respected: true, abi_return_struct_as_int: true, emit_debug_gdb_scripts: false, <ins> requires_uwtable: true, </ins> .. Default::default() }

Discussion:
From Gecko profiler uses EHABI information to walk stack. But since rustc doesn't generate EHABI, it cannot walk stack on generated code by rust. says, "-C panic=abort" causes that EHABI isn't emitted", so we need a option not to remove it (or don't remove EHABI even if -C panic=abort).
Note the same actually applies to EH_FRAME info on x86-64, which iirc the Firefox profiler also uses on x86-64. More generally, it can be desirable to have unwind info even when panic doesn't unwind.
For C/C++ code in Firefox we use  to ensure that the compiler generates these when is on: The equivalent for x86-64 is  which is apparently on by default. It seems like having a compiler option to enable this would be good enough, since the behavior here mirrors what gcc does: only emit unwind info if needed for exceptions/unwinding.
LLVM seems to turn on EHABI as default by (EnableARMEHABI is removed by this landing, but still has it) is similar issue for Win64 ABI.
This may or may not be related to , but I can prepare a patch like for the targets here. do you know what targets are in use by Firefox and would need this treatment?
Change:
} else { description }; <del> let span = if kind == dep_graph::dep_kinds::def_span { </del> <ins> let span = if kind == dep_graph::dep_kinds::def_span || reduce_queries { </ins> // The `def_span` query is used to calculate `default_span`, // so exit to avoid infinite recursion. None

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. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
<ins> pub struct MyStruct<'a> { field: &'a [u32], } impl MyStruct<'_> { pub fn new<'a>(field: &'a [u32]) -> MyStruct<'a> { Self { field } //~^ ERROR lifetime may not live long enough //~| ERROR lifetime may not live long enough } } trait Trait<'a> { fn new(field: &'a [u32]) -> MyStruct<'a>; } impl<'a> Trait<'a> for MyStruct<'_> { fn new(field: &'a [u32]) -> MyStruct<'a> { Self { field } //~^ ERROR lifetime may not live long enough //~| ERROR lifetime may not live long enough } } fn main() {} </ins>

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
Changing Self{field} to MyStruct{field} makes it build btw.
I haven't done a search for the exact commit, but on the playground this regressed between beta and nightly. label +regression-from-stable-to-nightly
This is due to the NLL stabilization PR , since it manifests with on 1.61 (with to allow feature flags). I'll be looking at it in a few hours when I get home!
Change:
} #[inline] <del> fn fn_sig_source_span(fn_sig_span: Span, body_span: Span) -> Span { original_sp(fn_sig_span, body_span).with_ctxt(body_span.ctxt()) } #[inline] </del> fn function_source_span(span: Span, body_span: Span) -> Span { let span = original_sp(span, body_span).with_ctxt(body_span.ctxt()); if body_span.contains(span) { span } else { body_span }

Discussion:
See below. Last nightly version that was known to work was 2021-04-19. Note that it says below but this is the version that installs as ! Similarly is the last known to work version but installed via as .
points at the following: searched nightlies: from nightly-2021-04-18 to nightly-2021-04-22 regressed nightly: nightly-2021-04-21 searched commits: from to regressed commit:
Because it was a small change, I have a guess about what I may need to check, but it would help to have an MCVE. I can't tell what code you're compiling that caused this. Can you provide a small example I can build locally? Thanks! cc:
By the way, where is the source for ? It looks like it is gone from github. I tried building , on the off chance that it might cause the same ICE with , but it built without issues.
We're having the same issue, if this helps: I'll see if I can get a minimal example
I don't have a minimal example, had no time to dig through the code yet to understand the problem. But you can easily reproduce it via
Ah! Thanks for providing the link to the source. I wasn't sure how to get it without access to the repo. Yes I can reproduce this. Looking into it now. Thanks!
Change:
if self.has_root() { return false; } <del> let mut iter = self.path[self.prefix_len()..].iter(); </del> <ins> let mut iter = self.path[self.prefix_remaining()..].iter(); </ins> match (iter.next(), iter.next()) { (Some(&b'.'), None) => true, (Some(&b'.'), Some(&b)) => self.is_sep_byte(b),

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. --This code panics on Windows: According to the documentation for , it should either succeed or return . Instead, it panics due to an out-of-range index: <!-- 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. --: The bug is also present in nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I can confirm this. The problem originates in . A minimal example:
It seems that the in causes the issue, I'll try to fix.
claim
Change:
hir_id: hir::HirId, span: Span, ) { <ins> // FIXME: ideally we would want to trim the def paths, but this is not // feasible with the current lint emission API (see issue #106126). </ins> match self { <del> CallToUnsafeFunction(did) if did.is_some() => tcx.emit_spanned_lint( </del> <ins> CallToUnsafeFunction(Some(did)) => tcx.emit_spanned_lint( </ins> UNSAFE_OP_IN_UNSAFE_FN, hir_id, span, UnsafeOpInUnsafeFnCallToUnsafeFunctionRequiresUnsafe { span, <del> function: &tcx.def_path_str(did.unwrap()), </del> <ins> function: &with_no_trimmed_paths!(tcx.def_path_str(*did)), </ins> }, ), <del> CallToUnsafeFunction(..) => tcx.emit_spanned_lint( </del> <ins> CallToUnsafeFunction(None) => tcx.emit_spanned_lint( </ins> UNSAFE_OP_IN_UNSAFE_FN, hir_id, span,

Discussion:
In some external crate, say : Main crate: : With , this gives the following ICE: <details<summary<strongBacktrace</strong</summary<p</p</detailsThis is because the lint to insert the name in the diagnostic message (this delays a good path bug), then the lint because it's in an external macro, which means we don't emit any diagnostic which triggers the good path bug. This ICE is currently preventing rustc from building with enabled. I see several ways to fix this: don't print the function name. It arguably carries little value, with the span already pointing to the offending function call, and brings THIR unsafeck in line with MIR unsafeck (cc ). 't trim the path. This might lead to longer messages but other lints already do this so it is probably acceptable? 't create the lint if we're in an external macro and we know the lint will be cancelled anyway. It's a little hacky and breaks down if changes are made to lint emission. the lint emission API to allow lint messages to be lazily evaluated. label +A-diagnostics +requires-nightly claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Error: Label thir-unsafeck can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Would not trimming the path also be acceptable ? (via )
It looks like some lints are already not trimming paths so this is probably acceptable? I can do that if that's the preferred option.
claim