jiebi/CodeConvo huggingface dataset:
Change:
} } <del> #[derive(Default)] pub struct PlaceholderExpander { </del> <ins> pub struct PlaceholderExpander<'a, 'b> { </ins> expanded_fragments: FxHashMap<ast::NodeId, AstFragment>, <ins> cx: &'a mut ExtCtxt<'b>, monotonic: bool, </ins> } <del> impl PlaceholderExpander { </del> <ins> impl<'a, 'b> PlaceholderExpander<'a, 'b> { pub fn new(cx: &'a mut ExtCtxt<'b>, monotonic: bool) -> Self { PlaceholderExpander { cx, expanded_fragments: FxHashMap::default(), monotonic } } </ins> pub fn add(&mut self, id: ast::NodeId, mut fragment: AstFragment) { fragment.mut_visit_with(self); self.expanded_fragments.insert(id, fragment);

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. --Context: "regression" caught by future-proofing CI from After working on reducing the code, I've identified the root cause of the ICE. For context: this patterns stem from "old" Rust code wanting to support proc-macros emitting item definitions in "statement" position for Rust: the trick is to use the to wrap an item-defs-emitting proc-macro call inside a function so that Rust doesn't interpret it as a statement, refusing the then-unstable stmt-emitting proc-macro call (). <!-- 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. --: Bonus: the ICE seems to have been introduced in between today's () and yesterday's nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc I suspect this is up your alley
searched nightlies: from nightly-2021-08-01 to nightly-2021-08-10 regressed nightly: nightly-2021-08-07 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +A-macros
Thanks nice job
Change:
} else { debug!("no type in expr = {:?}, count = {:?}, span = {:?}", expr, self.expr_count, expr.map(|e| e.span)); <ins> let ty = self.fcx.resolve_vars_if_possible(&ty); if let Some((unresolved_type, unresolved_type_span)) = self.fcx.unresolved_type_vars(&ty) { debug!("remained unresolved_type = {:?}, unresolved_type_span: {:?}", unresolved_type, unresolved_type_span); self.prev_unresolved_span = unresolved_type_span; } </ins> } } }

Discussion:
Consider for example this code (using ): This code will fail to compile due to types which cannot be fully inferred, with an error like this: However neither of these spans are anywhere near to the real problem which is the fact that variant is not inferred for . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
assign will do some investigation here and see if they can get an idea what's going on (and maybe fix)
Change:
// If this import is unresolved then create a dummy import // resolution for it so that later resolve stages won't complain. <del> self.import_dummy_binding(import); </del> <ins> self.import_dummy_binding(import, is_indeterminate); </ins> if let Some(err) = unresolved_import_error { if let ImportKind::Single { source, ref source_bindings, .. } = import.kind {

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2023-02-10 to nightly-2023-03-18 regressed nightly: nightly-2023-02-12 searched commit range: regressed commit: cc
Could you assign it to me, I am willing to try to solve the problem
Change:
<ins> enum E { A(u8, u8), } fn main() { let e = E::A(2, 3); match e { E::A(x @ ..) => {  //~ ERROR `x @` is not allowed in a tuple x //~ ERROR cannot find value `x` in this scope } }; } </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. --The bug exists in the beta, nightly, and stable build channels. : The error and the backtrace provided are produced by the stable build. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reduced: Edit: you can actually omit the enum declaration and it still crashes :thinking: `
oh, sorry, I've already got a fix. I'll post it soon. Though it may not be the best one.
Great! You should tweak not losing diags. For further reference, you could do when you work on an issue to avoid conflicts.
okay, thanks. Better late than never… claim
This is caused by , I believe. 1.44 emits errors w/o ICE'ing but 1.45 hits it. godbolt (1.44): godbolt (1.45):
Let's keep this open to track stable/beta backports.
The reference suggested this to be possible, which is how I came to suggest it to OP. We wanted to avoid naming them to not suggest any specific content.
here is another one: (assuming related)
The stable fix is reverted, and the nightly one is also but introduced another fix. I keep this open when that PR is beta-nominated, just in case.
We don't backport the fix in favor of this comment: So I'm just going to close this as fixed.
Change:
<del> Subproject commit e577c97b494be2815b215e3042207d6d4b7c5516 </del> <ins> Subproject commit 60fd8abfcae50629a3fc664bd809238fed039617 </ins>

Discussion:
There are a few issues of polish that I want to fix here: Although the installer internally supports multiple components there is no interface for actually selecting individual components. This is important because it allows to not install docs, which are 250 MB of the 50 MB install. Uninstallation can only be done through the original installer, which in many cases means the user is going to have to download the installer again. I want to put an uninstall script in the installation. This will require some refactoring and an upgrade of the installer manifest format.
This is a prereq for my plan to fix the .pkg uninstall issue
cc
cc
Change:
<del> // revisions: default miropt //[miropt]compile-flags: -Z mir-opt-level=2 // ~^ This flag is for #77668, it used to be ICE. </del> #![crate_type = "lib"] pub fn bar<P>( // Error won't happen if "bar" is not generic

Discussion:
Previously: Now: <!-- 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
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc
Change:
rustc_lexer::TokenKind::Ident => { SyntaxKind::from_keyword(token_text).unwrap_or(IDENT) } <del> rustc_lexer::TokenKind::InvalidIdent => { </del> <ins> rustc_lexer::TokenKind::InvalidPrefix | rustc_lexer::TokenKind::InvalidIdent => { </ins> err = "Ident contains invalid characters"; IDENT }

Discussion:
In the 2015 and 2018 editions, the following compiles (with warnings): ` [playground] The is taken as an identifier, although emoji aren't generally permitted in identifiers in any edition. I tested with 1.77.1. I think the underlying problem is that and in distinguish "identifiers" containing emoji (as rather than ), but don't have a way to make that distinction for . [playground]:
Regression from 1.57 to 1.58 (stable to stable). Very likely in , cc Regression from error to pass. Previous error: .
WG-prioritization assigning priority (). label -I-prioritize +P-low
thank you for the detailed report. will fix this.
Change:
background-color: #fff; } <ins> .source .sidebar { background-color: #fff; } </ins> .sidebar .location { border-color: #000; background-color: #fff;

Discussion:
What it looks like on : ! ! The strange color change on the side with the new sidebar style looks kind of tacky (especially at the bottom) and was probably not intended. Currently on : ! !
This is also broken on beta, tagging as such.
I'm looking into this. I see three potential options: the sidebar white on the src pages. This would look the same as the old styling. the width of the src view so it doesn't overlap with the sidebar. The sidebar is empty on src pages though so this looks kind of weird. If the sidebar retained its items from the other doc pages, this might look nice. the sidebar color and the background of the code block match so there isn't slightly different shades of grey on top of each other. I'm leaning toward option 1 for now but I think option 2 might be worth considering in the future. Thoughts?
While I am certainly not the most qualified to weigh in on this, my thoughts would be that 3 is less than desirable (having a random grey stripe on the left side looks out-of-place regardless of whether the color matches or not), 2 would unnecessarily decrease the usability of pages by decreasing the amount of horizontal space available to the code, and 1 is likely the best option. 3 would also mean that the code block would have padding on the right side but no padding on the left.
1 seems good
Ok. Option 1 it is!
Change:
} /// The available stability levels. <del> #[deriving(Eq,Ord,Clone)] </del> <ins> #[deriving(Eq,Ord,Clone,ToStr)] </ins> pub enum StabilityLevel { Deprecated, Experimental,

Discussion:
Nominating for milestone 5, production-ready
Can't be done without running resolve.
should be optional at most, as sometimes you want to see them
just a bug, removing milestone/nomination.
Still relevant though parenting to metabug on rustdoc_ng
/cc This would involve looking at the visibility of the associated trait and excluding the impl from the list if it's not public.
Didn't find a trait to test it with but it should be done now.
Change:
<del> //@ known-bug: #123153 pub struct wl_interface { pub version: str, } pub struct Interface { pub other_interfaces: &'static [&'static Interface], pub c_ptr: Option<&'static wl_interface>, } pub static mut wl_callback_interface: wl_interface = wl_interface { version: 0 }; pub static WL_CALLBACK_INTERFACE: Interface = Interface { other_interfaces: &[], c_ptr: Some(unsafe { &wl_callback_interface }) }; fn main() {} </del>

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. --(reduced) <details<summary<strongOriginal</strong</summary<p</p</details<!-- 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 , but I guess it just made the ICE easier to reach. cc
Nope unfortunately this one only reproduces with statics, and thus can't be reached on stable or before that PR. It's still not useful to look at to figure out why it's ICEing now, as the ICE is happening somewhere else entirely.
Change:
// Copy defaultness of the containing function. trait_assoc_ty.defaultness(tcx.defaultness(fn_def_id)); <del> // Copy type_of of the opaque. trait_assoc_ty.type_of(ty::EarlyBinder::bind(Ty::new_opaque( tcx, opaque_ty_def_id.to_def_id(), GenericArgs::identity_for_item(tcx, opaque_ty_def_id), ))); </del> trait_assoc_ty.is_type_alias_impl_trait(false); <del> // Copy generics_of of the opaque type item but the trait is the parent. trait_assoc_ty.generics_of({ let opaque_ty_generics = tcx.generics_of(opaque_ty_def_id); let opaque_ty_parent_count = opaque_ty_generics.parent_count; let mut params = opaque_ty_generics.params.clone(); let parent_generics = tcx.generics_of(trait_def_id); let parent_count = parent_generics.parent_count + parent_generics.params.len(); let mut trait_fn_params = tcx.generics_of(fn_def_id).params.clone(); for param in &mut params { param.index = param.index + parent_count as u32 + trait_fn_params.len() as u32 - opaque_ty_parent_count as u32; } trait_fn_params.extend(params); params = trait_fn_params; let param_def_id_to_index = params.iter().map(|param| (param.def_id, param.index)).collect(); ty::Generics { parent: Some(trait_def_id.to_def_id()), parent_count, params, param_def_id_to_index, has_self: opaque_ty_generics.has_self, has_late_bound_regions: opaque_ty_generics.has_late_bound_regions, host_effect_index: parent_generics.host_effect_index, } }); </del> // There are no inferred outlives for the synthesized associated type. trait_assoc_ty.inferred_outlives_of(&[]);

Discussion:
Minimal example (): outputs In the example, the implementation is irrelevant. The definition itself is the cause for error. Removing either the lifetime or the results in successful compilation as expected. I don't understand why it's causing a cycle error, but intuitively I don't see why it should be. Introducing an trait with a blanket implementation is a possible workaround and what I'll be doing while the issue exists.
Change:
return Suggestion::Macro; } else if kind == DefKind::Fn || kind == DefKind::AssocFn { return Suggestion::Function; <ins> } else if kind == DefKind::Field { return Suggestion::RemoveDisambiguator; </ins> } let prefix = match kind {

Discussion:
Unfortunately I don't have an easy-to-repro case. This happened while working on Rocket's docs. I renamed a method which made a previously valid link invalid and I got this ICE. Fixing the doc link fixes the error. Backtrace from rustc 1.54.0-nightly ( 2021-05-21) follows: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If someone can compile a build of rustdoc that comments out this line: you should get a much better error message that says exactly what went wrong (it will start with "incompatible link kind"), and that should give an idea of where the bug is.
can you link to the exact commit of Rocket that caused the ICE?
This is the current tip, You may be able to replicate this by referencing in the struct's docs in and then changing the method's name to something else. If this fails, I will try to create a reproducible case.
MCVE: label -E-needs-mcve
claim
Error: Parsing relabel command in failed: ...'needs-MCVE' '): rs'... Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'needs-mcve' '): rs'... Please let know if you're having trouble with this bot.
Change:
yoo: &'a U } <ins> // https://github.com/rust-lang/rust/issues/105150 struct InferredWhereBoundWithInlineBound<'a, T: ?Sized> //~^ ERROR outlives requirements can be inferred where T: 'a, { data: &'a T, } </ins> fn main() {}

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: Rustfix will fail to apply this: ` So we need to extend span to include the as well? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The relevant code is in , with . The should be computed using in the loop, instead of crafting a specific computation. Likewise, should use method. If using those 2 methods from is not enough to solve the issue, those methods should perhaps be adapted.
claim
release-assignment Haven't been able to focus on this. Releasing assignment.
claim
Progress report: I'm working on it.
claim
Change:
// but we have `T: Foo<X = ?1>` and `?1: Bar<X = // ?0>`). ty::Predicate::Projection(ref data) => <del> !infcx.any_unresolved_type_vars(&data.ty()), </del> <ins> infcx.any_unresolved_type_vars(&data.ty()), </ins> // We are only interested in `T: Foo<X = U>` predicates, whre // `U` references one of `unresolved_type_vars`. =)

Discussion:
Code: Using versions (similar crash; ): rustc 1.20.0-nightly ( 2017-07-08) rustc 1.18.0 ( 2017-06-06) I don't know too much about the compiler internals, but a bug search for "layout_of" didn't bring up anything that seemed relevant. So here you go. Seems similar to but I'm not using impl Trait?
Minimized a bit (52 lines): <details<summary(expand) </summary</details
This showed up in the crate's
A smaller version of what I believe is the same ICE:
yeah now that I look at it is that on stable OP's example has a different ICE error than on nightly, very alike to , while the one on nightly matches your example.
Bisected the nightly ICE using bisect-rust to () -- cc
Looks like the projection cache is dropping normalization obligations on the floor at This causes problems with my new evaluation code because it causes an earlier call into evaluation, which allows the cache pollution to proceed (I think).
Actually, the problem is that the projection cache is incompatible with 1-pass evaluation. Not sure how to solve this.
do you have further thoughts on this? The regression is now on beta :(
cc
I don't have any specific knowledge of how the caches involved here interact. It seems like layout code triggers this but the problem could arise in a number of other ways.
I have to talk to about this.
I can look into this, but not until Saturday.
triage: P-high
So I have a fix pending in but I'm not sure what to use for a regression test, since I don't want to add a dependency on futures.
"reasonably sized" test case which reproduces the error here.
I've minimized 's example to roughly the half .
The nightly is out and I no longer run into that ICE! On the other hand compiling this simple program now takes 8 minutes. The previous commit (before I introduced the ICE) is up from 6s to 1m51s.
I suggest you file a separate bug report for this.
hm I can't seem to get the commit linked above to compile? What compiler are you using to compile it "pre ICE"?
I'm compiling using stable and the nightly from the 28th from rustup... not sure why this would fail for you?

sorry I still can't get the code to compile. Can you list the exact commands you're using, along with the exact toolchain in rustup-style syntax?
The toolchains I tried are and . Whatever your environment you can reproduce this from scratch in Docker with:
Ok thanks for the repro Want to open a new issue with that so we can be sure to track it?
Will do! [edit: ]
Change:
<ins> // Verify that we do not ICE when we try to overwrite an anon-const's type because of a trait // cycle. // // compile-flags: -Zincremental-ignore-spans // revisions: cpass cfail // error-pattern: cycle detected when computing type of `Bar::N` #![feature(trait_alias)] #![crate_type="lib"] #[cfg(cpass)] trait Bar<const N: usize> {} #[cfg(cfail)] trait Bar<const N: dyn BB> {} trait BB = Bar<{ 2 + 1 }>; </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
cc
searched toolchains nightly-2023-04-20 through nightly-2023-04-28 Regression in nightly-2023-04-22 searched toolchains through Regression in
Change:
#[inline] #[stable(feature = "iter_repeat_n", since = "1.82.0")] pub fn repeat_n<T: Clone>(element: T, count: usize) -> RepeatN<T> { <del> let mut element = ManuallyDrop::new(element); if count == 0 { // SAFETY: we definitely haven't dropped it yet, since we only just got // passed it in, and because the count is zero the instance we're about // to create won't drop it, so to avoid leaking we need to now. unsafe { ManuallyDrop::drop(&mut element) }; } </del> <ins> let element = if count == 0 { // `element` gets dropped eagerly. MaybeUninit::uninit() } else { MaybeUninit::new(element) }; </ins> RepeatN { element, count } }

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 is technically different from as there's no UAF. However, using with has undefined behavior if you use the last/original element after moving the iterator, since the field has noalias properties. <details<summaryMiri Backtrace</summary<p</p</detailsWrapping the element using (or once we have that) should make this sound.
See also:
The minimal example is actually this: Because eagerly calls drop for . This basically boils down to Which is indeed I quite strongly think that this is a bug in miri and/or ( should use inside of itself probably?). That being said this is not yet decided (again, see the UCG issue) :/
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Yeah, it should -- someone just has to implement first. ;) See
I tweaked the title because while there is an experimental Miri flag to make Unique magical, codegen only has special treatment for Box.

<!-- 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. --currently unconditionally derives . However, it will also drop its inner object if is 0, which can cause a UAF if it's cloned afterwards. Running the above program segfaults: Edit: Made the segfault quicker/more reliable.
same issue with its implementation
cc I think you implemented this. ^^
WG-prioritization assigning priority (). label -I-prioritize +P-critical