jiebi/CodeConvo huggingface dataset:
Change:
pub(crate) struct Indeterminate(#[primary_span] pub(crate) Span); #[derive(Diagnostic)] <ins> #[diag(resolve_tool_module_imported)] pub(crate) struct ToolModuleImported { #[primary_span] pub(crate) span: Span, #[note] pub(crate) import: Span, } #[derive(Diagnostic)] </ins> #[diag(resolve_module_only)] pub(crate) struct ModuleOnly(#[primary_span] pub(crate) Span);

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
works with any tool attr also compiles but it probably... shouldn't.
label +S-bug-has-mcve
Triaged with . Steps performed: Reproduced: Formatted: No change, already formatted Reduced: Bisected: Regression in nightly-2022-04-17 couldn't nail down the particular commit: <details<summaryDetails</summary<prustc version: Icemelter version: v0.2.0 Icemelter command line: Do you have feedback about this report? Please ! </p</details
another one `
Change:
true } <del> /// In a move error that occurs on a call wihtin a loop, we try to identify cases where cloning </del> <ins> /// In a move error that occurs on a call within a loop, we try to identify cases where cloning </ins> /// the value would lead to a logic error. We infer these cases by seeing if the moved value is /// part of the logic to break the loop, either through an explicit `break` or if the expression /// is part of a `while let`.

Discussion:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or
Change:
stable("extern", |o| { o.optmulti("", "extern", "pass an --extern to rustc", "NAME=PATH") }), <ins> stable("extern-private", |o| { o.optmulti("", "extern-private", "pass an --extern to rustc (compatibility only)", "NAME=PATH") }), </ins> unstable("extern-html-root-url", |o| { o.optmulti("", "extern-html-root-url", "base URL to use for dependencies", "NAME=URL")

Discussion:
/cc
So the explosion is that somehow the crate index in the is broken, or at least not entirely right. Interestingly if you add to the then it no longer ICEs (but has the same ) Edit: So this looks like it's somehow a bug when trying to resolve it as a global name (both and prevent the iCE)
Maybe it's linked to ? If so, it's not in rustdoc but below.
I believe I've worked out approximately what's going on: Rustdoc freezes the compiler state (resolver, etc) as part of the setup to ready the instance. Since was made optional, and crate names are automatically part of the global scope, people stopped necessarily telling the compiler about the crates in their code. If a comment references a path in this manner, but the code itself doesn't, then the resolver frozen into the doesn't have that crate's metadata loaded into it. When we then ask the resolver to resolve a new path (e.g. ) it goes ahead and loads the crate into a different instance of the than will be used when we then try and use the later. It feels like the moment a is d it should also be locked so that it can never be modified again. It's also possible that rustdoc could be forced to enter the right context so that we never do this wrongly, but that's beyond me right now. Given that, , I feel this is probably either a bug in how is handling the resolver, or else a change in how the resolver behaves which either needs fixing, or changing in to cope.
My gut feeling is that we probably need to stop capturing/cloning the resolver as we do here: and instead try and find a resolver as part of the closure here: Of course, it looks like a has an immutable copy of the resolver's outputs, and no access to the resolver itself, urgh, and we have no easy way to inject changes into the context at this point.
I wonder why that type can be cloned in the first place...

I found an ICE when trying to document the [spirit-log][1] crate on the latest . Skimming through the backtrace, it looks like accessed an invalid index while traversing links within . Steps to reproduce: [1]:
Taking a look.
Actually, it's failing outside of rustdoc so I prefer to let someone else handle it. cc
I think this might be a bug (or at least mismatch between how uses the resolver infrastructure and how it's meant to work). See my comment here:
Change:
self.space(); } MatchKind::Postfix => { <del> self.print_expr_as_cond(expr); </del> <ins> self.print_expr_maybe_paren(expr, parser::PREC_POSTFIX, fixup); </ins> self.word_nbsp(".match"); } }

Discussion:
As of current nightly, produces this: which is not valid Rust syntax. The correct output would contain . tracking issue:
Change:
use rustc_span::symbol::{sym, Ident}; use rustc_span::Span; use rustc_trait_selection::autoderef::Autoderef; <ins> use std::slice; </ins> impl<'a, 'tcx> FnCtxt<'a, 'tcx> { /// Type-check `*oprnd_expr` with `oprnd_expr` type-checked already.

Discussion:
I tried to compile this code: I expected the code to compile Instead, it failed to compile with this lifetime error: If I change the function in these ways it compiles. This compiles successfully on Stable Rust 1.45.0 back to 1.26.0 (when lifetimes were stabilized) This fails to compile on these versions(haven't tried previous ones in the same channels): 1.46.0-beta.2 (2020-07-23 ) 1.47.0-nightly (2020-07-28 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Let’s find the culprit for this. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as and removing .
Regressed in which is a roll-up, likely
cc in case you want to fix this is a follow-up of
The explicit lifetimes are edit: the lt of doesn't matter
assigning to but they will probably need to delegate as there time is limited in near future.
Will look into this today. claim
This code compiles in Rust 1.17 but not in Rust 1.18+: unifies DerefMut/IndexMut to use the "fix-up" path originally used when performing method calls, so it broadens the bug to assignments as well.
Okay, this is an issue near convertplaceoptomutable. Just re-infer the index type and re-do the coercion is sufficient to fix the regionck failure (). However I am not sure why the existing code does not work. This piece of code is last touched in . cc do you have any clue why the existing approach does not work well with regionck?
Hmm.. I would not have expected that code to have to change, since the failure seems to try to make the anonymous lifetime on in the method match , which it should not. I think your patch is sound, but touching the "wrong" thing.

Basically now we are creating new lifetimes for the index, when I would have thought that the container type's reference's lifetime needs adjustment. So looking at , I'm guessing is taking the wrong region and should instead invent a new one?
This issue is not related to anonymous lifetime actually, if you spell out the lifetime explicitly it's still the same. The root cause has been identified and that line actually is the culprit, a detailed analysis can be found in .
I a couple of examples of workarounds that allowed the function to compile, with the same signature.
Change:
let mut ei = bb_eis.pop().unwrap(); match ei.top_elts.get_tt(ei.idx) { <del> TtToken(_, MatchNt(_, name, _, _)) => { </del> <ins> TtToken(span, MatchNt(_, name, _, _)) => { </ins> let name_string = token::get_ident(name); let match_cur = ei.match_cur; (&mut ei.matches[match_cur]).push(Rc::new(MatchedNonterminal( <del> parse_nt(&mut rust_parser, name_string.get())))); </del> <ins> parse_nt(&mut rust_parser, span, name_string.get())))); </ins> ei.idx += 1us; ei.match_cur += 1; }

Discussion:
I work on Windows 8.1 64-bit, rustc version: BTW, the same ICE occurred for my but it did not print backtrace with and I don't know why.
Change:
) -> Option<ClosureOutlivesSubject<'tcx>> { let tcx = infcx.tcx; <del> debug!("try_promote_type_test_subject(ty = {:?})", ty); </del> let ty = tcx.fold_regions(ty, |r, _depth| { let region_vid = self.to_region_vid(r);

Discussion:
This code compiles after although it shouldn't: () This is similar to in that we're not taking into account placeholder regions when "promoting" type-tests from the closure to its caller: label T-types regression-from-stable-to-beta C-bug A-NLL I-unsound <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess it would be an easy fix claim
The unsoundness exploitation in can easily be adapted for this issue, so it is in fact a soundness issue:
issue touched in today's T-compiler meeting, . Will also be discussed tomorrow during the T-types meeting.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
ty::Bound(..) | ty::Error(..) <del> | ty::GeneratorWitness(..) </del> | ty::GeneratorWitnessMIR(..) | ty::Infer(..) | ty::Alias(..)

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Copyright 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. pub struct Foo<'a, A>(&'a A); impl<'a, A> Foo<'a, A> { pub fn new(a: &'a A) -> Foo<'a, A> { Foo(a) } } </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> // Copyright 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. pub struct Foo<'a, A>(&'a A); impl<'a, A> Foo<'a, A> { pub fn new(a: &'a A) -> Foo<'a, A> { Foo(a) } } </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> error[E0597]: `x` does not live long enough --> $DIR/generic-slice.rs:15:9 | LL | impl<'a, T: 'static> Generic<'a, T> { |      -- lifetime `'a` defined here ... LL |         &x |         ^^ |         | |         borrowed value does not live long enough |         using this value as a constant requires that `x` is borrowed for `'a` LL | LL |     }; |     - `x` dropped here while still borrowed error[E0597]: `x` does not live long enough --> $DIR/generic-slice.rs:27:5 | LL |     &x |     ^^ |     | |     borrowed value does not live long enough |     using this value as a static requires that `x` is borrowed for `'static` LL | LL | }; | - `x` dropped here while still borrowed error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0597`. </ins>

Discussion:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.
Change:
// // Note that we do not supply the parent generics when using // `min_const_generics`. <del> Some(parent_def_id.to_def_id()) </del> <ins> Some(parent_did) </ins> } } else { let parent_node = tcx.parent_hir_node(hir_id);

Discussion:
<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(effects) -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [adtdestructor] computing impl for [checkwellformed] checking that is well-formed -- label +F-constmutrefs +F-consttrait_impl +F-effects
Regression in of
doesn't require any features actually, rip
Removed irrelevant errors:
Minimized: or
Change:
use crate::ty::{self, ConstInt, DefIdTree, ParamConst, ScalarInt, Ty, TyCtxt, TypeFoldable}; use rustc_apfloat::ieee::{Double, Single}; use rustc_data_structures::fx::FxHashMap; <ins> use rustc_data_structures::sso::SsoHashSet; </ins> use rustc_hir as hir; use rustc_hir::def::{self, CtorKind, DefKind, Namespace}; use rustc_hir::def_id::{CrateNum, DefId, DefIdSet, CRATE_DEF_INDEX, LOCAL_CRATE};

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: program either compiled successful or compiler generate an error Instead, this happened: rustc eats 100% CPU for several minutes, but nothing generated. I compile this code using both and before I began to write this issue, but compiler do not compile even after this issue is submitted. <!-- 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
Slightly smaller:
Actually, I am very curious that, why rustc do not reach the recursion limit.
Oh sorry, you're right, it does hit the recursion limit if I let it run long enough (about 10 seconds).
Here's a proper minimization:
Partial backtrace of the hang: <details</details
So it actually hangs while trying to print the overflow error :laughing:
Bisected:
looks suspicious.
hang but generate a failed massage:
Assigning and removing .
Change:
STD_STRING_REGEX = re.compile(r"^(alloc::(w+::)+)String$") <del> STD_STR_REGEX = re.compile(r"^&str$") STD_SLICE_REGEX = re.compile(r"^&[.+]$") </del> <ins> STD_STR_REGEX = re.compile(r"^&(mut )?str$") STD_SLICE_REGEX = re.compile(r"^&(mut )?[.+]$") </ins> STD_OS_STRING_REGEX = re.compile(r"^(std::ffi::(w+::)+)OsString$") STD_VEC_REGEX = re.compile(r"^(alloc::(w+::)+)Vec<.+>$") STD_VEC_DEQUE_REGEX = re.compile(r"^(alloc::(w+::)+)VecDeque<.+>$")

Discussion:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools
Change:
<ins> // check-pass // edition:2021 #![feature(generic_const_exprs)] #![allow(incomplete_features)] #[allow(unused)] async fn foo<'a>() { let _data = &mut [0u8; { 1 + 4 }]; bar().await } async fn bar() {} fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you add the to the code example instead to make it more easily runnable in the future?
claim
Change:
<ins> // check-pass #![feature(generic_associated_types)] trait Trait { type Assoc<'a>; fn with_assoc(f: impl FnOnce(Self::Assoc<'_>)); } impl Trait for () { type Assoc<'a> = i32; fn with_assoc(f: impl FnOnce(Self::Assoc<'_>)) { f(5i32) } } fn main() {} </ins>

Discussion:
This code ] produces these errors: in 1.54.0-nightly (2021-05-27 ) Note that you get one of these errors even if you , implying that the compiler first infers that is , then complains that and are different.
I suspect that this will be fixed by
label +A-associated-items +A-closures +T-compiler
Fixed in latest nightly
GATs issue triage: not blocking. Works now, just needs test.
Change:
pub(crate) struct DocFS { sync_only: bool, errors: Option<Sender<String>>, <ins> pool: ThreadPool, </ins> } impl DocFS { pub(crate) fn new(errors: Sender<String>) -> DocFS { <del> DocFS { sync_only: false, errors: Some(errors) } </del> <ins> const MINIMUM_NB_THREADS: usize = 2; DocFS { sync_only: false, errors: Some(errors), pool: ThreadPool::new( available_parallelism() .map(|nb| max(nb.get(), MINIMUM_NB_THREADS)) .unwrap_or(MINIMUM_NB_THREADS), ), } </ins> } pub(crate) fn set_sync_only(&mut self, sync_only: bool) {

Discussion:
As discovered by in rust-lang/cargo, a Cargo test is intermittently failing on Windows because a source file generated by Rustdoc is not being written before the process exits. The suspected issue is that Rustdoc spawns asynchronous writes here: However, Rustdoc never checks that the writes are completed. We should add a mechanism that prevents the process from exiting before these write tasks are completed. One possible solution: Add a field to . Increment at the start of , and decrement at the end of the spawned Rayon task. Add a method that spin-loops until is zero. (Alternatively: use a condition variable, and have notify the condvar when is decremented.) Either call explicitly in the end of the Rustdoc process, or add it as a implementation to . cc
Change:
<ins> comes from a file with a name that begins with < comes from a file with a name that ends with > </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. --Requirement: Create an empty file called '', i.e. using <!-- 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
Hmm, we should only disallow (since that's what we use for non-real "files") although I guess or even just might be a valid path itself? Internally we can tell apart between the two, I'm guessing this is to avoid tools seeing something with or in it and misinterpreting it as not a real file? But in that case we'd want a real error not an assert. cc
Marked as p-medium based on the discussion on the
PR with fix:
Change:
/// /// [`poll()`]: crate::future::Future::poll #[inline] <del> #[stable(feature = "futures_api", since = "1.36.0")] </del> <ins> #[unstable(feature = "local_waker", issue = "118959")] </ins> pub fn wake(self) { // The actual wakeup call is delegated through a virtual function call // to the implementation which is defined by the executor.

Discussion:
The following code leaks memory: Miri error: The equivalent code with , so I think this is a bug. Cc
I guess this is not too surprising... has but has nothing like that.
Oh, that's may bad. I assumed that RawWaker handled ownership. I can push a PR today in the evening.
This leads to a miri-test-libstd failure every day, would be nice to get a fix soon. :)