Question:
I tried this code: I expected to see this happen: no warnings Instead, this happened: : cc
It looks like there is an upstream issue about this , but it seems like this shouldn't be an issue for dependents as long as is on edition < 2024.
It is expected for the lint to lint on macro-generated code. It is also expected for the lint to lint on all editions (it is not a edition dependent lint).
What am I meant to do as a downstream of a macro crate that hasn't fixed it then? I don't want to be ing a FCW, but there's nothing else I can do to clear this warning from my code. (And that implies that the planned "hard error in 2027" actually means for all editions, not just Edition 2027?)
Allow the lint. Report the issue upstream. Consider switching to an unaffected crate. That's understandable, but until the upstream crate is fixed I don't have a better solution. Note, that it is quite unlikely that this point that the lint will become deny-by-default in Rust 2024. No, if hard-error there is, it would only be for edition 2027 and higher, not below.
Why?
Detecting and ignoring macro-generated code for a lint where possible is the expected behavior of rustc.
Because, in particular for macro-generated code, we can't lint at the source since, well it is only generated when using the proc-macro or . Yes, but we must still emit the warning in macro-generated code, since the goal is to make the lint deny-by-default and then hard-error in a future edition, and without the warn it would go straight to hard-error which is not good.
Is there no ability to enable the lint when in the same crate/workspace but disable it for "foreign" macro-generated spans?
Yes, but can't rely on this. Also, not all macros have tests. The lint is only warn-by-default so it wouldn't break any test yet. If you mean: "don't lint on external macro", that is possible for but not for proc-macro since they are always external. We did an crater run, to evaluate the impact, before merging the lint in We had many cases with derive-macro, most of them (82.2%) where fixable by a , the rest would need manual intervention, the crate in question here was detected, and I reported the issue upstream with the fix that would fix the issue.
that was why I was thinking of trying to reason cross-workspace, but hmm, true. And actually, proc macros are worse: they can , so at least some are going to almost certainly slip through either way.
I would love if we had the ability to do that, but unfortunately doesn't have that information. Workspaces are a Cargo-only concept. :eyes:
I was hoping that we could do something where cargo helps us out here by describing which things we pay attention to, but I am fully prepared to believe that such is not tractable, even if only because no one has figured out if the infra for doing such a thing is even possible.
Yeah, unfortunately there isn't really anything else the compiler can do, it would be great if we could lint at the macro definition but due to the way they work that isn't possible, we are therefore forced to do the second "best" thing and lint at the usage. should be make it clearer that the "macro needs to change". So let's reclassify this issue as not-a-bug but as a discussion. labels -C-bug +C-discussion

| `Debug` is not local | move the `impl` block outside of this constant `_IMPL_DEBUG` | <ins> = note: the macro `non_local_macro::non_local_impl` defines the non-local `impl`, and may need to be changed = note: the macro `non_local_macro::non_local_impl` may come from an old version of the `non_local_macro` crate, try updating your dependency with `cargo update -p non_local_macro` </ins> = note: `impl` may be usable in bounds, etc. from outside the expression, which might e.g. make something constructible that previously wasn't, because it's still on a publicly-visible type = note: an `impl` is never scoped, even when it is nested inside an item, as it may impact type checking outside of that item, which can be the case if neither the trait or the self type are at the same nesting level as the `impl` <del> = note: the macro `non_local_macro::non_local_impl` may come from an old version of the `non_local_macro` crate, try updating your dependency with `cargo update -p non_local_macro` </del> = note: items in an anonymous const item (`const _: () = { ... }`) are treated as in the same scope as the anonymous const's declaration = note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363> = note: `#[warn(non_local_definitions)]` on by default


Question:
I tried this code: I expected to see this happen: no warnings Instead, this happened: : cc
It looks like there is an upstream issue about this , but it seems like this shouldn't be an issue for dependents as long as is on edition < 2024.
It is expected for the lint to lint on macro-generated code. It is also expected for the lint to lint on all editions (it is not a edition dependent lint).
What am I meant to do as a downstream of a macro crate that hasn't fixed it then? I don't want to be ing a FCW, but there's nothing else I can do to clear this warning from my code. (And that implies that the planned "hard error in 2027" actually means for all editions, not just Edition 2027?)
Allow the lint. Report the issue upstream. Consider switching to an unaffected crate. That's understandable, but until the upstream crate is fixed I don't have a better solution. Note, that it is quite unlikely that this point that the lint will become deny-by-default in Rust 2024. No, if hard-error there is, it would only be for edition 2027 and higher, not below.
Why?
Detecting and ignoring macro-generated code for a lint where possible is the expected behavior of rustc.
Because, in particular for macro-generated code, we can't lint at the source since, well it is only generated when using the proc-macro or . Yes, but we must still emit the warning in macro-generated code, since the goal is to make the lint deny-by-default and then hard-error in a future edition, and without the warn it would go straight to hard-error which is not good.
Is there no ability to enable the lint when in the same crate/workspace but disable it for "foreign" macro-generated spans?
Yes, but can't rely on this. Also, not all macros have tests. The lint is only warn-by-default so it wouldn't break any test yet. If you mean: "don't lint on external macro", that is possible for but not for proc-macro since they are always external. We did an crater run, to evaluate the impact, before merging the lint in We had many cases with derive-macro, most of them (82.2%) where fixable by a , the rest would need manual intervention, the crate in question here was detected, and I reported the issue upstream with the fix that would fix the issue.
that was why I was thinking of trying to reason cross-workspace, but hmm, true. And actually, proc macros are worse: they can , so at least some are going to almost certainly slip through either way.
I would love if we had the ability to do that, but unfortunately doesn't have that information. Workspaces are a Cargo-only concept. :eyes:
I was hoping that we could do something where cargo helps us out here by describing which things we pay attention to, but I am fully prepared to believe that such is not tractable, even if only because no one has figured out if the infra for doing such a thing is even possible.
Yeah, unfortunately there isn't really anything else the compiler can do, it would be great if we could lint at the macro definition but due to the way they work that isn't possible, we are therefore forced to do the second "best" thing and lint at the usage. should be make it clearer that the "macro needs to change". So let's reclassify this issue as not-a-bug but as a discussion. labels -C-bug +C-discussion

LL | m!(); | ---- in this macro invocation | <ins> = note: the macro `m` defines the non-local `impl`, and may need to be changed </ins> = note: `impl` may be usable in bounds, etc. from outside the expression, which might e.g. make something constructible that previously wasn't, because it's still on a publicly-visible type = note: an `impl` is never scoped, even when it is nested inside an item, as it may impact type checking outside of that item, which can be the case if neither the trait or the self type are at the same nesting level as the `impl` = note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [tagforvariant] computing variant tag for enum [evaluateobligation] evaluating trait selection obligation --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
That is the transmutability check asking for the discriminant of an uninhabited variant. I'm not sure what that code is doing with this information, but probably it makes sense to just remove the assertion and treat uninhabited variants like niched variants -- writing their discriminant is a NOP, but then the validation we do will definitely fail as the uninhabited variant cannot actually be represented in-memory. Cc
claim

variant_index: VariantIdx, ) -> InterpResult<'tcx, Option<(ScalarInt, usize)>> { match self.layout_of(ty)?.variants { <del> abi::Variants::Single { index } => { assert_eq!(index, variant_index); Ok(None) } </del> <ins> abi::Variants::Single { .. } => Ok(None), </ins> abi::Variants::Multiple { tag_encoding: TagEncoding::Direct,


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [tagforvariant] computing variant tag for enum [evaluateobligation] evaluating trait selection obligation --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
That is the transmutability check asking for the discriminant of an uninhabited variant. I'm not sure what that code is doing with this information, but probably it makes sense to just remove the assertion and treat uninhabited variants like niched variants -- writing their discriminant is a NOP, but then the validation we do will definitely fail as the uninhabited variant cannot actually be represented in-memory. Cc
claim

assert!(def.is_enum()); let layout = ty_and_layout.layout; <del> if let Variants::Multiple { tag_field, .. } = layout.variants() { // For enums (but not coroutines), the tag field is // currently always the first field of the layout. assert_eq!(*tag_field, 0); } </del> <ins> // Computes the variant of a given index. let layout_of_variant = |index| { let tag = cx.tcx.tag_for_variant((ty_and_layout.ty, index)); let variant_def = Def::Variant(def.variant(index)); let variant_ty_and_layout = ty_and_layout.for_variant(&cx, index); Self::from_variant(variant_def, tag, variant_ty_and_layout, layout.size, cx) }; </ins> <del> let variants = def.discriminants(cx.tcx()).try_fold( Self::uninhabited(), |variants, (idx, ref discriminant)| { let tag = cx.tcx.tag_for_variant((ty_and_layout.ty, idx)); let variant_def = Def::Variant(def.variant(idx)); let variant_ty_and_layout = ty_and_layout.for_variant(&cx, idx); let variant = Self::from_variant( variant_def, tag, variant_ty_and_layout, layout.size, cx, </del> <ins> // We consider three kinds of enums, each demanding a different // treatment of their layout computation: // 1. enums that are uninhabited // 2. enums for which all but one variant is uninhabited // 3. enums with multiple inhabited variants match layout.variants() { _ if layout.abi.is_uninhabited() => { // Uninhabited enums are usually (always?) zero-sized. In // the (unlikely?) event that an uninhabited enum is // non-zero-sized, this assert will trigger an ICE, and this // code should be modified such that a `layout.size` amount // of uninhabited bytes is returned instead. // // Uninhabited enums are currently implemented such that // their layout is described with `Variants::Single`, even // though they don't necessarily have a 'single' variant to // defer to. That said, we don't bother specifically // matching on `Variants::Single` in this arm because the // behavioral principles here remain true even if, for // whatever reason, the compiler describes an uninhabited // enum with `Variants::Multiple`. assert_eq!(layout.size, Size::ZERO); Ok(Self::uninhabited()) } Variants::Single { index } => { // `Variants::Single` on non-uninhabited enums denotes that // the enum delegates its layout to the variant at `index`. layout_of_variant(*index) } Variants::Multiple { tag_field, .. } => { // `Variants::Multiple` denotes an enum with multiple // inhabited variants. The layout of such an enum is the // disjunction of the layouts of its tagged variants. // For enums (but not coroutines), the tag field is // currently always the first field of the layout. assert_eq!(*tag_field, 0); let variants = def.discriminants(cx.tcx()).try_fold( Self::uninhabited(), |variants, (idx, ref discriminant)| { let variant = layout_of_variant(idx)?; Result::<Self, Err>::Ok(variants.or(variant)) }, </ins> )?; <del> Result::<Self, Err>::Ok(variants.or(variant)) }, )?; return Ok(Self::def(Def::Adt(def)).then(variants)); </del> <ins> return Ok(Self::def(Def::Adt(def)).then(variants)); } } </ins> } /// Constructs a `Tree` from a 'variant-like' layout.


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [tagforvariant] computing variant tag for enum [evaluateobligation] evaluating trait selection obligation --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
That is the transmutability check asking for the discriminant of an uninhabited variant. I'm not sure what that code is doing with this information, but probably it makes sense to just remove the assertion and treat uninhabited variants like niched variants -- writing their discriminant is a NOP, but then the validation we do will definitely fail as the uninhabited variant cannot actually be represented in-memory. Cc
claim

<del> //@ known-bug: rust-lang/rust#125811 mod assert { use std::mem::{Assume, BikeshedIntrinsicFrom}; pub fn is_transmutable<Src, Dst>() where Dst: BikeshedIntrinsicFrom<Src>, { } } #[repr(C)] struct Zst; enum V0 { B(!), } enum V2 { V = 2, } enum Lopsided { Smol(Zst), Lorg(V0), } #[repr(C)] #[repr(C)] struct Dst(Lopsided, V2); fn should_pad_variants() { assert::is_transmutable::<Src, Dst>(); } </del>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [tagforvariant] computing variant tag for enum [evaluateobligation] evaluating trait selection obligation --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
That is the transmutability check asking for the discriminant of an uninhabited variant. I'm not sure what that code is doing with this information, but probably it makes sense to just remove the assertion and treat uninhabited variants like niched variants -- writing their discriminant is a NOP, but then the validation we do will definitely fail as the uninhabited variant cannot actually be represented in-memory. Cc
claim

<ins> //@ check-pass //! Tests that we do not regress rust-lang/rust#125811 #![feature(transmutability)] fn assert_transmutable<T>() where (): std::mem::BikeshedIntrinsicFrom<T> {} enum Uninhabited {} enum SingleInhabited { X, Y(Uninhabited) } enum SingleUninhabited { X(Uninhabited), Y(Uninhabited), } fn main() { assert_transmutable::<Uninhabited>(); assert_transmutable::<SingleInhabited>(); assert_transmutable::<SingleUninhabited>(); } </ins>


Question:
<!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: should have been handled elsewhere', 'error: internal compiler error: should have been handled elsewhere' 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: --
also repros with or with 2015 if you remove the :)
Regression in nightly-2020-12-20 fetching (via remote github) commits from max(, 2020-12-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 9 commit[0] 2020-12-18: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[1] 2020-12-18: Auto merge of - GuillaumeGomez:str-to-symbol, r=jyn514 commit[2] 2020-12-19: Auto merge of - mibac138:fn-fat-arrow-return, r=davidtwco commit[3] 2020-12-19: Auto merge of - davidtwco:issue--const-param-attrs, r=lcnr commit[4] 2020-12-19: Auto merge of - JohnTitor:rollup-a31s996, r=JohnTitor commit[5] 2020-12-19: Auto merge of - jackh726:binder-refactor-part-2, r=lcnr commit[6] 2020-12-19: Auto merge of - CDirkx:ipaddr-const, r=oli-obk commit[7] 2020-12-19: Auto merge of - matthewjasper:revert-eval-order, r=nikomatsakis commit[8] 2020-12-19: Auto merge of - Nadrieril:usefulness-merging, r=varkor
This is also kinda bad because rustc does not tell you what you did wrong (theres no error shown) mvce:
very likely

pub(super) fn parse_ty_for_where_clause(&mut self) -> PResult<'a, P<Ty>> { self.parse_ty_common( AllowPlus::Yes, <del> AllowCVariadic::Yes, </del> <ins> AllowCVariadic::No, </ins> RecoverQPath::Yes, RecoverReturnSign::OnlyFatArrow, None,


Question:
<!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: should have been handled elsewhere', 'error: internal compiler error: should have been handled elsewhere' 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: --
also repros with or with 2015 if you remove the :)
Regression in nightly-2020-12-20 fetching (via remote github) commits from max(, 2020-12-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 9 commit[0] 2020-12-18: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[1] 2020-12-18: Auto merge of - GuillaumeGomez:str-to-symbol, r=jyn514 commit[2] 2020-12-19: Auto merge of - mibac138:fn-fat-arrow-return, r=davidtwco commit[3] 2020-12-19: Auto merge of - davidtwco:issue--const-param-attrs, r=lcnr commit[4] 2020-12-19: Auto merge of - JohnTitor:rollup-a31s996, r=JohnTitor commit[5] 2020-12-19: Auto merge of - jackh726:binder-refactor-part-2, r=lcnr commit[6] 2020-12-19: Auto merge of - CDirkx:ipaddr-const, r=oli-obk commit[7] 2020-12-19: Auto merge of - matthewjasper:revert-eval-order, r=nikomatsakis commit[8] 2020-12-19: Auto merge of - Nadrieril:usefulness-merging, r=varkor
This is also kinda bad because rustc does not tell you what you did wrong (theres no error shown) mvce:
very likely

match allow_c_variadic { AllowCVariadic::Yes => TyKind::CVarArgs, AllowCVariadic::No => { <del> // FIXME(Centril): Should we just allow `...` syntactically </del> <ins> // FIXME(c_variadic): Should we just allow `...` syntactically </ins> // anywhere in a type and use semantic restrictions instead? <ins> // NOTE: This may regress certain MBE calls if done incorrectly. </ins> let guar = self .dcx() .emit_err(NestedCVariadicType { span: lo.to(self.prev_token.span) });


Question:
<!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: should have been handled elsewhere', 'error: internal compiler error: should have been handled elsewhere' 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: --
also repros with or with 2015 if you remove the :)
Regression in nightly-2020-12-20 fetching (via remote github) commits from max(, 2020-12-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 9 commit[0] 2020-12-18: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[1] 2020-12-18: Auto merge of - GuillaumeGomez:str-to-symbol, r=jyn514 commit[2] 2020-12-19: Auto merge of - mibac138:fn-fat-arrow-return, r=davidtwco commit[3] 2020-12-19: Auto merge of - davidtwco:issue--const-param-attrs, r=lcnr commit[4] 2020-12-19: Auto merge of - JohnTitor:rollup-a31s996, r=JohnTitor commit[5] 2020-12-19: Auto merge of - jackh726:binder-refactor-part-2, r=lcnr commit[6] 2020-12-19: Auto merge of - CDirkx:ipaddr-const, r=oli-obk commit[7] 2020-12-19: Auto merge of - matthewjasper:revert-eval-order, r=nikomatsakis commit[8] 2020-12-19: Auto merge of - Nadrieril:usefulness-merging, r=varkor
This is also kinda bad because rustc does not tell you what you did wrong (theres no error shown) mvce:
very likely

<ins> // A bare `...` represents `CVarArgs` (`VaListImpl<'_>`) in function argument type // position without being a proper type syntactically. // This test ensures that we do not regress certain MBE calls would we ever promote // `...` to a proper type syntactically. //@ check-pass macro_rules! ck { ($ty:ty) => { compile_error!(""); }; (...) => {}; } ck!(...); fn main() {} </ins>


Question:
<!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: should have been handled elsewhere', 'error: internal compiler error: should have been handled elsewhere' 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: --
also repros with or with 2015 if you remove the :)
Regression in nightly-2020-12-20 fetching (via remote github) commits from max(, 2020-12-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 9 commit[0] 2020-12-18: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[1] 2020-12-18: Auto merge of - GuillaumeGomez:str-to-symbol, r=jyn514 commit[2] 2020-12-19: Auto merge of - mibac138:fn-fat-arrow-return, r=davidtwco commit[3] 2020-12-19: Auto merge of - davidtwco:issue--const-param-attrs, r=lcnr commit[4] 2020-12-19: Auto merge of - JohnTitor:rollup-a31s996, r=JohnTitor commit[5] 2020-12-19: Auto merge of - jackh726:binder-refactor-part-2, r=lcnr commit[6] 2020-12-19: Auto merge of - CDirkx:ipaddr-const, r=oli-obk commit[7] 2020-12-19: Auto merge of - matthewjasper:revert-eval-order, r=nikomatsakis commit[8] 2020-12-19: Auto merge of - Nadrieril:usefulness-merging, r=varkor
This is also kinda bad because rustc does not tell you what you did wrong (theres no error shown) mvce:
very likely

fn f2<'a>(x: u8, y: Vec<&'a ...>) {} //~^ ERROR C-variadic type `...` may not be nested inside another type <ins> // Regression test for issue #125847. fn f3() where for<> ...: {} //~^ ERROR C-variadic type `...` may not be nested inside another type </ins> fn main() { let _recovery_witness: () = 0; //~^ ERROR: mismatched types


Question:
<!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: should have been handled elsewhere', 'error: internal compiler error: should have been handled elsewhere' 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: --
also repros with or with 2015 if you remove the :)
Regression in nightly-2020-12-20 fetching (via remote github) commits from max(, 2020-12-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 9 commit[0] 2020-12-18: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[1] 2020-12-18: Auto merge of - GuillaumeGomez:str-to-symbol, r=jyn514 commit[2] 2020-12-19: Auto merge of - mibac138:fn-fat-arrow-return, r=davidtwco commit[3] 2020-12-19: Auto merge of - davidtwco:issue--const-param-attrs, r=lcnr commit[4] 2020-12-19: Auto merge of - JohnTitor:rollup-a31s996, r=JohnTitor commit[5] 2020-12-19: Auto merge of - jackh726:binder-refactor-part-2, r=lcnr commit[6] 2020-12-19: Auto merge of - CDirkx:ipaddr-const, r=oli-obk commit[7] 2020-12-19: Auto merge of - matthewjasper:revert-eval-order, r=nikomatsakis commit[8] 2020-12-19: Auto merge of - Nadrieril:usefulness-merging, r=varkor
This is also kinda bad because rustc does not tell you what you did wrong (theres no error shown) mvce:
very likely

LL | fn f2<'a>(x: u8, y: Vec<&'a ...>) {} |                             ^^^ <ins> error[E0743]: C-variadic type `...` may not be nested inside another type --> $DIR/variadic-ffi-nested-syntactic-fail.rs:8:21 | LL | fn f3() where for<> ...: {} |                     ^^^ </ins> error[E0308]: mismatched types <del> --> $DIR/variadic-ffi-nested-syntactic-fail.rs:8:33 </del> <ins> --> $DIR/variadic-ffi-nested-syntactic-fail.rs:12:33 </ins> | LL |     let _recovery_witness: () = 0; |                            --   ^ expected `()`, found integer |                            | |                            expected due to this <del> error: aborting due to 3 previous errors </del> <ins> error: aborting due to 4 previous errors </ins> Some errors have detailed explanations: E0308, E0743. For more information about an error, try `rustc --explain E0308`.


Question:
Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

{ write!(f, "n{}", Indent(n + 4))?; } <ins> let last_input_index = self.inputs.values.len().checked_sub(1); </ins> for (i, input) in self.inputs.values.iter().enumerate() { <del> if i > 0 { match line_wrapping_indent { None => write!(f, ", ")?, Some(n) => write!(f, ",n{}", Indent(n + 4))?, }; } </del> if let Some(selfty) = input.to_self() { match selfty { clean::SelfValue => {


Question:
Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

write!(f, "{}: ", input.name)?; input.type_.print(cx).fmt(f)?; } <ins> match (line_wrapping_indent, last_input_index) { (_, None) => (), (None, Some(last_i)) if i != last_i => write!(f, ", ")?, (None, Some(_)) => (), (Some(n), Some(last_i)) if i != last_i => write!(f, ",n{}", Indent(n + 4))?, (Some(_), Some(_)) => write!(f, ",n")?, } </ins> } if self.c_variadic { match line_wrapping_indent { None => write!(f, ", ...")?, <del> Some(n) => write!(f, "n{}...", Indent(n + 4))?, </del> <ins> Some(n) => write!(f, "{}...n", Indent(n + 4))?, </ins> }; } match line_wrapping_indent { None => write!(f, ")")?, <del> Some(n) => write!(f, "n{})", Indent(n))?, </del> <ins> Some(n) => write!(f, "{})", Indent(n))?, </ins> }; self.print_output(cx).fmt(f)


Question:
Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

impl Foo { // @has async_fn/struct.Foo.html <del> // @has - '//*[@class="method"]' 'pub async fn complicated_lifetimes( &self, context: &impl Bar ) -> impl Iterator<Item = &usize>' </del> <ins> // @has - '//*[@class="method"]' 'pub async fn complicated_lifetimes( &self, context: &impl Bar, ) -> impl Iterator<Item = &usize>' </ins> pub async fn complicated_lifetimes(&self, context: &impl Bar) -> impl Iterator<Item = &usize> { [0].iter() }


Question:
Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

pub fn create( ) -> Padding00000000000000000000000000000000000000000000000000000000000000000000000000000000
   No newline at end of file
pub fn create() -> Padding00000000000000000000000000000000000000000000000000000000000000000000000000000000
   No newline at end of file


Question:
Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

fn poll_write( self, cx: &mut Option<String>,  buf: &mut [usize]   buf: &mut [usize],  ) -> Option<Result<usize, Error>>;     fn poll_flush(self, cx: &mut Option<String>) -> Option<Result<(), Error>>;     fn poll_close(self, cx: &mut Option<String>) -> Option<Result<(), Error>>;


Question:
Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

fn poll_write_vectored( self, cx: &mut Option<String>,  bufs: &[usize]   bufs: &[usize],  ) -> Option<Result<usize, Error>> { ... } }  No newline at end of file


Question:
Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

// @has impl_trait/fn.func2.html // @has - '//pre[@class="rust item-decl"]' "func2<T>(" // @has - '//pre[@class="rust item-decl"]' "_x: impl Deref<Target = Option<T>> + Iterator<Item = T>," <del> // @has - '//pre[@class="rust item-decl"]' "_y: impl Iterator<Item = u8> )" </del> <ins> // @has - '//pre[@class="rust item-decl"]' "_y: impl Iterator<Item = u8>, )" </ins> // @!has - '//pre[@class="rust item-decl"]' 'where' pub use impl_trait_aux::func2;


Question:
Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

// @matches foo/fn.function_with_a_really_long_name.html '//*[@class="rust item-decl"]//code' " //     function_with_a_really_long_name(n //        parameter_one: i32,n <del> //        parameter_two: i32n </del> <ins> //        parameter_two: i32,n </ins> //    ) -> Option<i32>$" pub fn function_with_a_really_long_name(parameter_one: i32, parameter_two: i32) -> Option<i32> { Some(parameter_one + parameter_two)


Question:
Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

pub use reexports::foo; // @has 'foo/outer/inner/fn.foo_crate.html' '//pre[@class="rust item-decl"]' 'pub(crate) fn foo_crate()' pub(crate) use reexports::foo_crate; <del> // @has 'foo/outer/inner/fn.foo_super.html' '//pre[@class="rust item-decl"]' 'pub(in outer) fn foo_super( )' </del> <ins> // @has 'foo/outer/inner/fn.foo_super.html' '//pre[@class="rust item-decl"]' 'pub(in outer) fn foo_super()' </ins> pub(super) use::reexports::foo_super; // @!has 'foo/outer/inner/fn.foo_self.html' pub(self) use reexports::foo_self;


Question:
<!-- ICE: 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): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [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

use rustc_span::symbol::{kw, Symbol}; use rustc_span::Span; <ins> #[instrument(level = "debug", skip(tcx))] </ins> pub(super) fn generics_of(tcx: TyCtxt<'_>, def_id: LocalDefId) -> ty::Generics { use rustc_hir::*;


Question:
<!-- ICE: 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): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [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

// FIXME(#43408) always enable this once `lazy_normalization` is // stable enough and does not need a feature gate anymore. Node::AnonConst(_) => { <del> let parent_def_id = tcx.hir().get_parent_item(hir_id); </del> <ins> let parent_did = tcx.parent(def_id.to_def_id()); // We don't do this unconditionally because the `DefId` parent of an anon const // might be an implicitly created closure during `async fn` desugaring. This would // have the wrong generics. // // i.e. `async fn foo<'a>() { let a = [(); { 1 + 2 }]; bar().await() }` // would implicitly have a closure in its body that would be the parent of // the `{ 1 + 2 }` anon const. This closure's generics is simply a witness // instead of `['a]`. let parent_did = if let DefKind::AnonConst = tcx.def_kind(parent_did) { parent_did } else { tcx.hir().get_parent_item(hir_id).to_def_id() }; debug!(?parent_did); </ins> let mut in_param_ty = false; for (_parent, node) in tcx.hir().parent_iter(hir_id) {


Question:
<!-- ICE: 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): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [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

// // This has some implications for how we get the predicates available to the anon const // see `explicit_predicates_of` for more information on this <del> let generics = tcx.generics_of(parent_def_id.to_def_id()); </del> <ins> let generics = tcx.generics_of(parent_did); </ins> let param_def_idx = generics.param_def_id_to_index[&param_id.to_def_id()]; // In the above example this would be .params[..N#0] let own_params = generics.params_to(param_def_idx as usize, tcx).to_owned();


Question:
<!-- ICE: 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): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [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

// // 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);


Question:
<!-- ICE: 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): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [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

Node::Expr(Expr { kind: ExprKind::Repeat(_, constant), .. }) if constant.hir_id() == hir_id => { <del> Some(parent_def_id.to_def_id()) </del> <ins> Some(parent_did) </ins> } // Exclude `GlobalAsm` here which cannot have generics. Node::Expr(&Expr { kind: ExprKind::InlineAsm(asm), .. })


Question:
<!-- ICE: 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): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [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

_ => false, }) => { <del> Some(parent_def_id.to_def_id()) </del> <ins> Some(parent_did) </ins> } _ => None, }


Question:
<!-- ICE: 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): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [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

<ins> // Given an anon const `a`: `{ N }` and some anon const `b` which references the // first anon const: `{ [1; a] }`. `b` should not have any generics as it is not // a simple `N` argument nor is it a repeat expr count. // // On the other hand `b` *is* a repeat expr count and so it should inherit its // parents generics as part of the `const_evaluatable_unchecked` fcw (#76200). // // In this specific case however `b`'s parent should be `a` and so it should wind // up not having any generics after all. If `a` were to inherit its generics from // the enclosing item then the reference to `a` from `b` would contain generic // parameters not usable by `b` which would cause us to ICE. fn bar<const N: usize>() {} fn foo<const N: usize>() { bar::<{ [1; N] }>(); //~^ ERROR: generic parameters may not be used in const operations } fn main() {} </ins>


Question:
<!-- ICE: 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): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [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

<ins> error: generic parameters may not be used in const operations --> $DIR/repeat_expr_hack_gives_right_generics.rs:16:17 | LL |     bar::<{ [1; N] }>(); |                 ^ cannot perform const operation using `N` | = help: const parameters may only be used as standalone arguments, i.e. `N` = help: add `#![feature(generic_const_exprs)]` to allow generic const expressions error: aborting due to 1 previous error </ins>


Question:
<!-- 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: then shows I'd expect DWATdecl_line to be 9 (the line where the macro is called), not 5 (the line where the static is defined inside the macro). <!-- 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. --:
cc

}; use rustc_session::config::{self, DebugInfo, Lto}; use rustc_span::symbol::Symbol; <del> use rustc_span::FileName; </del> <ins> use rustc_span::{hygiene, FileName, DUMMY_SP}; </ins> use rustc_span::{FileNameDisplayPreference, SourceFile}; use rustc_symbol_mangling::typeid_for_trait_ref; use rustc_target::abi::{Align, Size};


Question:
<!-- 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: then shows I'd expect DWATdecl_line to be 9 (the line where the macro is called), not 5 (the line where the static is defined inside the macro). <!-- 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. --:
cc

// We may want to remove the namespace scope if we're in an extern block (see // https://github.com/rust-lang/rust/pull/46457#issuecomment-351750952). let var_scope = get_namespace_for_item(cx, def_id); <del> let span = tcx.def_span(def_id); </del> <ins> let span = hygiene::walk_chain_collapsed(tcx.def_span(def_id), DUMMY_SP); </ins> let (file_metadata, line_number) = if !span.is_dummy() { let loc = cx.lookup_debug_loc(span.lo());


Question:
<!-- 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: then shows I'd expect DWATdecl_line to be 9 (the line where the macro is called), not 5 (the line where the static is defined inside the macro). <!-- 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. --:
cc

<ins> //@ ignore-lldb // Test that static debug info is not collapsed with #[collapse_debuginfo(external)] //@ compile-flags:-g // === GDB TESTS =================================================================================== // gdb-command:info line collapse_debuginfo_static_external::FOO // gdb-check:[...]Line 15[...] #[collapse_debuginfo(external)] macro_rules! decl_foo { () => { static FOO: u32 = 0; }; } decl_foo!(); fn main() { // prevent FOO from getting optimized out std::hint::black_box(&FOO); } </ins>


Question:
<!-- 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: then shows I'd expect DWATdecl_line to be 9 (the line where the macro is called), not 5 (the line where the static is defined inside the macro). <!-- 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. --:
cc

<ins> //@ ignore-lldb // Test that static debug info is collapsed with #[collapse_debuginfo(yes)] //@ compile-flags:-g // === GDB TESTS =================================================================================== // gdb-command:info line collapse_debuginfo_static::FOO // gdb-check:[...]Line 19[...] #[collapse_debuginfo(yes)] macro_rules! decl_foo { () => { static FOO: u32 = 0; }; } decl_foo!(); fn main() { // prevent FOO from getting optimized out std::hint::black_box(&FOO); } </ins>


Question:
<!-- 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. --(hand-reduced) <details<summary<strong(original)</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. --: Command: I put the option to remove "async fn" error, but I guess it is not an essential option to trigger ICE. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE location: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
searched nightlies: from nightly-2022-02-19 to nightly-2024-06-19 regressed nightly: nightly-2024-03-08 searched commit range: regressed commit: ()

} // Resolve any lifetime variables that may have been introduced during normalization. let Ok((trait_bounds, impl_bounds)) = infcx.fully_resolve((trait_bounds, impl_bounds)) else { <del> // This code path is not reached in any tests, but may be reachable. If // this is triggered, it should be converted to `delayed_bug` and the // triggering case turned into a test. tcx.dcx().bug("encountered errors when checking RPITIT refinement (resolution)"); </del> <ins> // If resolution didn't fully complete, we cannot continue checking RPITIT refinement, and // delay a bug as the original code contains load-bearing errors. tcx.dcx().delayed_bug("encountered errors when checking RPITIT refinement (resolution)"); return; </ins> }; // For quicker lookup, use an `IndexSet` (we don't use one earlier because


Question:
<!-- 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. --(hand-reduced) <details<summary<strong(original)</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. --: Command: I put the option to remove "async fn" error, but I guess it is not an essential option to trigger ICE. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE location: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
searched nightlies: from nightly-2022-02-19 to nightly-2024-06-19 regressed nightly: nightly-2024-03-08 searched commit range: regressed commit: ()

<ins> // This is a non-regression test for issue #126670 where RPITIT refinement checking encountered // errors during resolution and ICEd. //@ edition: 2018 pub trait Mirror { type Assoc; } impl<T: ?Sized> Mirror for () { //~^ ERROR the type parameter `T` is not constrained type Assoc = T; } pub trait First { async fn first() -> <() as Mirror>::Assoc; //~^ ERROR type annotations needed } impl First for () { async fn first() {} } fn main() {} </ins>


Question:
<!-- 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. --(hand-reduced) <details<summary<strong(original)</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. --: Command: I put the option to remove "async fn" error, but I guess it is not an essential option to trigger ICE. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE location: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
searched nightlies: from nightly-2022-02-19 to nightly-2024-06-19 regressed nightly: nightly-2024-03-08 searched commit range: regressed commit: ()

<ins> error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates --> $DIR/refine-resolution-errors.rs:9:6 | LL | impl<T: ?Sized> Mirror for () { |      ^ unconstrained type parameter error[E0282]: type annotations needed --> $DIR/refine-resolution-errors.rs:15:5 | LL |     async fn first() -> <() as Mirror>::Assoc; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type error: aborting due to 2 previous errors Some errors have detailed explanations: E0207, E0282. For more information about an error, try `rustc --explain E0207`. </ins>


Question:
Reviewing PR had some oversight regarding valid utf8 checks. This was graciously brought to our (meaning myself and attention by in . Fix should really just be changing to setting to , unless we decide there may be some merit to iterating again through the buffer.
label T-libs C-cleanup O-windows
label -needs-triage

#[inline] pub(crate) fn extend_from_slice(&mut self, other: &[u8]) { self.bytes.extend_from_slice(other); <del> self.is_known_utf8 = self.is_known_utf8 || self.next_surrogate(0).is_none(); </del> <ins> self.is_known_utf8 = false; </ins> } }


Question:
Reviewing PR had some oversight regarding valid utf8 checks. This was graciously brought to our (meaning myself and attention by in . Fix should really just be changing to setting to , unless we decide there may be some merit to iterating again through the buffer.
label T-libs C-cleanup O-windows
label -needs-triage

string.push(CodePoint::from_u32(0xD800).unwrap()); check_utf8_boundary(&string, 3); } <ins> #[test] fn wobbled_wtf8_plus_bytes_isnt_utf8() { let mut string: Wtf8Buf = unsafe { Wtf8::from_bytes_unchecked(b"xEDxA0x80").to_owned() }; assert!(!string.is_known_utf8); string.extend_from_slice(b"some utf-8"); assert!(!string.is_known_utf8); } #[test] fn wobbled_wtf8_plus_str_isnt_utf8() { let mut string: Wtf8Buf = unsafe { Wtf8::from_bytes_unchecked(b"xEDxA0x80").to_owned() }; assert!(!string.is_known_utf8); string.push_str("some utf-8"); assert!(!string.is_known_utf8); } #[test] fn unwobbly_wtf8_plus_utf8_is_utf8() { let mut string: Wtf8Buf = Wtf8Buf::from_str("hello world"); assert!(string.is_known_utf8); string.push_str("some utf-8"); assert!(string.is_known_utf8); } </ins>


Question:
Running with doesn't include a trailing so the next shell prompt gets smooshed on: I can't imagine this is intentional since all other options seem to include the newline. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +E-easy +A-cli +T-compiler -needs-triage
claim

for print in &sess.opts.prints { if print.kind == PrintKind::LinkArgs { <del> let content = format!("{cmd:?}"); </del> <ins> let content = format!("{cmd:?}n"); </ins> print.out.overwrite(&content, sess); } }


Question:
Running with doesn't include a trailing so the next shell prompt gets smooshed on: I can't imagine this is intentional since all other options seem to include the newline. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +E-easy +A-cli +T-compiler -needs-triage
claim

.run_unchecked(); out.assert_stdout_contains("lfoo"); out.assert_stdout_contains("lbar"); <ins> assert!(out.stdout_utf8().ends_with('n')); </ins> }


Question:
<!-- 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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

false } } <ins> } else if tcx.trait_is_auto(trait_ref.def_id) { tcx.dcx().span_delayed_bug( tcx.def_span(obligation.predicate.def_id), "associated types not allowed on auto traits", ); false </ins> } else { bug!("unexpected builtin trait with associated type: {trait_ref:?}") }


Question:
<!-- 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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

<del> //@ known-bug: #117829 #![feature(auto_traits)] trait B {} auto trait Z<T> where T: Z<u16>, <T as Z<u16>>::W: B, { type W; } fn main() {} </del>


Question:
<!-- 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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

<del> //@ known-bug: #117829 auto trait Z<'a, T: ?Sized> where T: Z<'a, u16>, for<'b> <T as Z<'b, u16>>::W: Clone, { type W: ?Sized; } </del>


Question:
<!-- 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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

<ins> error[E0380]: auto traits cannot have associated items --> $DIR/assoc-ty.rs:10:10 | LL | auto trait Trait { |            ----- auto traits cannot have associated items LL | LL |     type Output; |     -----^^^^^^- help: remove these associated items error[E0658]: auto traits are experimental and possibly buggy --> $DIR/assoc-ty.rs:8:1 | LL | / auto trait Trait { LL | | LL | |     type Output; LL | | LL | | } | |_^ | = note: see issue #13231 <https://github.com/rust-lang/rust/issues/13231> for more information = help: add `#![feature(auto_traits)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error[E0308]: mismatched types --> $DIR/assoc-ty.rs:15:36 | LL |     let _: <() as Trait>::Output = (); |            ---------------------   ^^ expected associated type, found `()` |            | |            expected due to this | = note: expected associated type `<() as Trait>::Output` found unit type `()` = help: consider constraining the associated type `<() as Trait>::Output` to `()` or calling a method that returns `<() as Trait>::Output` = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html error: aborting due to 3 previous errors Some errors have detailed explanations: E0308, E0380, E0658. For more information about an error, try `rustc --explain E0308`. </ins>


Question:
<!-- 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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

<ins> error[E0380]: auto traits cannot have associated items --> $DIR/assoc-ty.rs:10:10 | LL | auto trait Trait { |            ----- auto traits cannot have associated items LL | LL |     type Output; |     -----^^^^^^- help: remove these associated items error[E0658]: auto traits are experimental and possibly buggy --> $DIR/assoc-ty.rs:8:1 | LL | / auto trait Trait { LL | | LL | |     type Output; LL | | LL | | } | |_^ | = note: see issue #13231 <https://github.com/rust-lang/rust/issues/13231> for more information = help: add `#![feature(auto_traits)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error[E0308]: mismatched types --> $DIR/assoc-ty.rs:15:36 | LL |     let _: <() as Trait>::Output = (); |            ---------------------   ^^ types differ |            | |            expected due to this | = note: expected associated type `<() as Trait>::Output` found unit type `()` = help: consider constraining the associated type `<() as Trait>::Output` to `()` or calling a method that returns `<() as Trait>::Output` = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html error: aborting due to 3 previous errors Some errors have detailed explanations: E0308, E0380, E0658. For more information about an error, try `rustc --explain E0308`. </ins>


Question:
<!-- 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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

<ins> //@ revisions: current next //@[next] compile-flags: -Znext-solver //@ ignore-compare-mode-next-solver (explicit revisions) // Tests that projection doesn't explode if we accidentally // put an associated type on an auto trait. auto trait Trait { //~^ ERROR auto traits are experimental and possibly buggy type Output; //~^ ERROR auto traits cannot have associated items } fn main() { let _: <() as Trait>::Output = (); //~^ ERROR mismatched types } </ins>


Question:
<!-- 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. --The error cleared up when I cleared out /target/ and I couldn't make a minimal example, but I thought I'd post the panic message anyway in case its helpful. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is that a... panic during a panic during a panic during a panic?
This specific panic should be fixed by along with some of the reasons to panic while panicking.
So I don't think there's anything else to do here but link and close the issue.

} #[inline(always)] <del> pub fn local_def_path_hash_to_def_id( &self, hash: DefPathHash, err_msg: &dyn std::fmt::Debug, ) -> LocalDefId { </del> <ins> /// Returns `None` if the `DefPathHash` does not correspond to a `LocalDefId` /// in the current compilation session. This can legitimately happen if the /// `DefPathHash` is from a `DefId` in an upstream crate or, during incr. comp., /// if the `DefPathHash` is from a previous compilation session and /// the def-path does not exist anymore. pub fn local_def_path_hash_to_def_id(&self, hash: DefPathHash) -> Option<LocalDefId> { </ins> debug_assert!(hash.stable_crate_id() == self.table.stable_crate_id); <del> #[cold] #[inline(never)] fn err(err_msg: &dyn std::fmt::Debug) -> ! { panic!("{err_msg:?}") } </del> self.table .def_path_hash_to_index .get(&hash.local_hash()) .map(|local_def_index| LocalDefId { local_def_index }) <del> .unwrap_or_else(|| err(err_msg)) </del> } pub fn def_path_hash_to_def_index_map(&self) -> &DefPathHashMap {


Question:
<!-- 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. --The error cleared up when I cleared out /target/ and I couldn't make a minimal example, but I thought I'd post the panic message anyway in case its helpful. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is that a... panic during a panic during a panic during a panic?
This specific panic should be fixed by along with some of the reasons to panic while panicking.
So I don't think there's anything else to do here but link and close the issue.

/// has been removed. fn extract_def_id(&self, tcx: TyCtxt<'_>) -> Option<DefId> { if tcx.fingerprint_style(self.kind) == FingerprintStyle::DefPathHash { <del> Some(tcx.def_path_hash_to_def_id( DefPathHash(self.hash.into()), &("Failed to extract DefId", self.kind, self.hash), )) </del> <ins> tcx.def_path_hash_to_def_id(DefPathHash(self.hash.into())) </ins> } else { None }


Question:
<!-- 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. --The error cleared up when I cleared out /target/ and I couldn't make a minimal example, but I thought I'd post the panic message anyway in case its helpful. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is that a... panic during a panic during a panic during a panic?
This specific panic should be fixed by along with some of the reasons to panic while panicking.
So I don't think there's anything else to do here but link and close the issue.

if tcx.fingerprint_style(dep_node.kind) == FingerprintStyle::HirId { let (local_hash, local_id) = Fingerprint::from(dep_node.hash).split(); let def_path_hash = DefPathHash::new(tcx.stable_crate_id(LOCAL_CRATE), local_hash); <del> let def_id = tcx .def_path_hash_to_def_id( def_path_hash, &("Failed to extract HirId", dep_node.kind, dep_node.hash), ) .expect_local(); </del> <ins> let def_id = tcx.def_path_hash_to_def_id(def_path_hash)?.expect_local(); </ins> let local_id = local_id .as_u64() .try_into()


Question:
<!-- 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. --The error cleared up when I cleared out /target/ and I couldn't make a minimal example, but I thought I'd post the panic message anyway in case its helpful. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is that a... panic during a panic during a panic during a panic?
This specific panic should be fixed by along with some of the reasons to panic while panicking.
So I don't think there's anything else to do here but link and close the issue.

// If we get to this point, then all of the query inputs were green, // which means that the definition with this hash is guaranteed to // still exist in the current compilation session. <del> self.tcx.def_path_hash_to_def_id( def_path_hash, &("Failed to convert DefPathHash", def_path_hash), ) </del> <ins> match self.tcx.def_path_hash_to_def_id(def_path_hash) { Some(r) => r, None => panic!("Failed to convert DefPathHash {def_path_hash:?}"), } </ins> } fn decode_attr_id(&mut self) -> rustc_span::AttrId {


Question:
<!-- 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. --The error cleared up when I cleared out /target/ and I couldn't make a minimal example, but I thought I'd post the panic message anyway in case its helpful. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is that a... panic during a panic during a panic during a panic?
This specific panic should be fixed by along with some of the reasons to panic while panicking.
So I don't think there's anything else to do here but link and close the issue.

/// Converts a `DefPathHash` to its corresponding `DefId` in the current compilation /// session, if it still exists. This is used during incremental compilation to /// turn a deserialized `DefPathHash` into its current `DefId`. <del> pub fn def_path_hash_to_def_id( self, hash: DefPathHash, err_msg: &dyn std::fmt::Debug, ) -> DefId { </del> <ins> pub fn def_path_hash_to_def_id(self, hash: DefPathHash) -> Option<DefId> { </ins> debug!("def_path_hash_to_def_id({:?})", hash); let stable_crate_id = hash.stable_crate_id();


Question:
<!-- 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. --The error cleared up when I cleared out /target/ and I couldn't make a minimal example, but I thought I'd post the panic message anyway in case its helpful. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is that a... panic during a panic during a panic during a panic?
This specific panic should be fixed by along with some of the reasons to panic while panicking.
So I don't think there's anything else to do here but link and close the issue.

// If this is a DefPathHash from the local crate, we can look up the // DefId in the tcx's `Definitions`. if stable_crate_id == self.stable_crate_id(LOCAL_CRATE) { <del> self.untracked .definitions .read() .local_def_path_hash_to_def_id(hash, err_msg) .to_def_id() </del> <ins> Some(self.untracked.definitions.read().local_def_path_hash_to_def_id(hash)?.to_def_id()) </ins> } else { <del> self.def_path_hash_to_def_id_extern(hash, stable_crate_id) </del> <ins> Some(self.def_path_hash_to_def_id_extern(hash, stable_crate_id)) </ins> } }


Question:
<!-- 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. --The error cleared up when I cleared out /target/ and I couldn't make a minimal example, but I thought I'd post the panic message anyway in case its helpful. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is that a... panic during a panic during a panic during a panic?
This specific panic should be fixed by along with some of the reasons to panic while panicking.
So I don't think there's anything else to do here but link and close the issue.

} /// Try to force a dep node to execute and see if it's green. <ins> /// /// Returns true if the query has actually been forced. It is valid that a query /// fails to be forced, e.g. when the query key cannot be reconstructed from the /// dep-node or when the query kind outright does not support it. </ins> #[inline] #[instrument(skip(self, frame), level = "debug")] fn try_force_from_dep_node(self, dep_node: DepNode, frame: Option<&MarkFrame<'_>>) -> bool { let cb = self.dep_kind_info(dep_node.kind); if let Some(f) = cb.force_from_dep_node { <del> if let Err(value) = panic::catch_unwind(panic::AssertUnwindSafe(|| { f(self, dep_node); })) { if !value.is::<rustc_errors::FatalErrorMarker>() { print_markframe_trace(self.dep_graph(), frame); </del> <ins> match panic::catch_unwind(panic::AssertUnwindSafe(|| f(self, dep_node))) { Err(value) => { if !value.is::<rustc_errors::FatalErrorMarker>() { print_markframe_trace(self.dep_graph(), frame); } panic::resume_unwind(value) </ins> } <del> panic::resume_unwind(value) </del> <ins> Ok(query_has_been_forced) => query_has_been_forced, </ins> } <del> true </del> } else { false }


Question:
<!-- 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. --The error cleared up when I cleared out /target/ and I couldn't make a minimal example, but I thought I'd post the panic message anyway in case its helpful. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is that a... panic during a panic during a panic during a panic?
This specific panic should be fixed by along with some of the reasons to panic while panicking.
So I don't think there's anything else to do here but link and close the issue.

<ins> // If it is impossible to find query arguments just from the hash // compiler should treat the node as red // In this test prior to fixing compiler was having problems figuring out // drop impl for T inside of m //@ revisions:cfail1 cfail2 //@ compile-flags: --crate-type=lib //@ build-pass pub trait P { type A; } struct S; impl P for S { type A = C; } struct T<D: P>(D::A, Z<D>); struct Z<D: P>(D::A, String); impl<D: P> T<D> { pub fn i() -> Self { loop {} } } enum C { #[cfg(cfail1)] Up(()), #[cfg(cfail2)] Lorry(()), } pub fn m() { T::<S>::i(); } </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

#[diag(parse_use_eq_instead)] pub(crate) struct UseEqInstead { #[primary_span] <ins> #[suggestion(style = "verbose", applicability = "machine-applicable", code = "=")] </ins> pub span: Span, <del> #[suggestion(style = "verbose", applicability = "machine-applicable", code = "")] pub suggestion: Span, </del> } #[derive(Diagnostic)]


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

&& expected.iter().any(|tok| matches!(tok, TokenType::Token(TokenKind::Eq))) { // Likely typo: `=` → `==` in let expr or enum item <del> return Err(self.dcx().create_err(UseEqInstead { span: self.token.span, suggestion: self.token.span.with_lo(self.token.span.lo() + BytePos(1)), })); </del> <ins> return Err(self.dcx().create_err(UseEqInstead { span: self.token.span })); </ins> } if self.token.is_keyword(kw::Move) && self.prev_token.is_keyword(kw::Async) {


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

= help: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }` help: try using `=` instead | <del> LL -     B == 2 LL +     B = 2 | </del> <ins> LL |     B = 2 |       ~ </ins> error: expected item, found `==` --> $DIR/issue-101477-enum.rs:6:7


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

| help: try using `=` instead | <del> LL -     let x == 2; LL +     let x = 2; | </del> <ins> LL |     let x = 2; |           ~ </ins> error: aborting due to 1 previous error


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> const A: usize ⩵ 2; //~^ ERROR unknown start of token: u{2a75} //~| ERROR unexpected `==` </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> error: unknown start of token: u{2a75} --> $DIR/unicode-double-equals-recovery.rs:1:16 | LL | const A: usize ⩵ 2; |                ^ | help: Unicode character '⩵' (Two Consecutive Equals Signs) looks like '==' (Double Equals Sign), but it is not | LL | const A: usize == 2; |                ~~ error: unexpected `==` --> $DIR/unicode-double-equals-recovery.rs:1:16 | LL | const A: usize ⩵ 2; |                ^ | help: try using `=` instead | LL | const A: usize = 2; |                ~ error: aborting due to 2 previous errors </ins>


Question:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.

.label = declared `#[non_exhaustive]` here .help = consider a manual implementation of `Default` <ins> builtin_macros_non_generic_pointee = the `#[pointee]` attribute may only be used on generic parameters </ins> builtin_macros_non_unit_default = the `#[default]` attribute may only be used on unit enum variants .help = consider a manual implementation of `Default`


Question:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.

use rustc_span::{Span, Symbol}; use thin_vec::{ThinVec, thin_vec}; <ins> use crate::errors; </ins> macro_rules! path { ($span:expr, $($part:ident)::*) => { vec![$(Ident::new(sym::$part, $span),)*] } }


Question:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.

push: &mut dyn FnMut(Annotatable), _is_const: bool, ) { <ins> item.visit_with(&mut DetectNonGenericPointeeAttr { cx }); </ins> let (name_ident, generics) = if let Annotatable::Item(aitem) = item && let ItemKind::Struct(struct_data, g) = &aitem.kind {


Question:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.

} } } <ins> struct DetectNonGenericPointeeAttr<'a, 'b> { cx: &'a ExtCtxt<'b>, } impl<'a, 'b> rustc_ast::visit::Visitor<'a> for DetectNonGenericPointeeAttr<'a, 'b> { fn visit_attribute(&mut self, attr: &'a rustc_ast::Attribute) -> Self::Result { if attr.has_name(sym::pointee) { self.cx.dcx().emit_err(errors::NonGenericPointee { span: attr.span }); } } fn visit_generic_param(&mut self, param: &'a rustc_ast::GenericParam) -> Self::Result { let mut error_on_pointee = AlwaysErrorOnGenericParam { cx: self.cx }; match &param.kind { GenericParamKind::Type { default } => { // The `default` may end up containing a block expression. // The problem is block expressions  may define structs with generics. // A user may attach a #[pointee] attribute to one of these generics // We want to catch that. The simple solution is to just // always raise a `NonGenericPointee` error when this happens. // // This solution does reject valid rust programs but, // such a code would have to, in order: // - Define a smart pointer struct. // - Somewhere in this struct definition use a type with a const generic argument. // - Calculate this const generic in a expression block. // - Define a new smart pointer type in this block. // - Have this smart pointer type have more than 1 generic type. // In this case, the inner smart pointer derive would be complaining that it // needs a pointer attribute. Meanwhile, the outer macro would be complaining // that we attached a #[pointee] to a generic type argument while helpfully // informing the user that #[pointee] can only be attached to generic pointer arguments rustc_ast::visit::visit_opt!(error_on_pointee, visit_ty, default); } GenericParamKind::Const { .. } | GenericParamKind::Lifetime => { rustc_ast::visit::walk_generic_param(&mut error_on_pointee, param); } } } fn visit_ty(&mut self, t: &'a rustc_ast::Ty) -> Self::Result { let mut error_on_pointee = AlwaysErrorOnGenericParam { cx: self.cx }; error_on_pointee.visit_ty(t) } } struct AlwaysErrorOnGenericParam<'a, 'b> { cx: &'a ExtCtxt<'b>, } impl<'a, 'b> rustc_ast::visit::Visitor<'a> for AlwaysErrorOnGenericParam<'a, 'b> { fn visit_attribute(&mut self, attr: &'a rustc_ast::Attribute) -> Self::Result { if attr.has_name(sym::pointee) { self.cx.dcx().emit_err(errors::NonGenericPointee { span: attr.span }); } } } </ins>


Question:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.

#[label] pub testing_span: Span, } <ins> #[derive(Diagnostic)] #[diag(builtin_macros_non_generic_pointee)] pub(crate) struct NonGenericPointee { #[primary_span] pub span: Span, } </ins>


Question:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.

ptr: &'a T, } <ins> #[derive(SmartPointer)] #[repr(transparent)] struct PointeeOnField<'a, #[pointee] T: ?Sized> { #[pointee] //~^ ERROR: the `#[pointee]` attribute may only be used on generic parameters ptr: &'a T } #[derive(SmartPointer)] #[repr(transparent)] struct PointeeInTypeConstBlock<'a, T: ?Sized = [u32; const { struct UhOh<#[pointee] T>(T); 10 }]> { //~^ ERROR: the `#[pointee]` attribute may only be used on generic parameters ptr: &'a T, } #[derive(SmartPointer)] #[repr(transparent)] struct PointeeInConstConstBlock< 'a, T: ?Sized, const V: u32 = { struct UhOh<#[pointee] T>(T); 10 }> //~^ ERROR: the `#[pointee]` attribute may only be used on generic parameters { ptr: &'a T, } #[derive(SmartPointer)] #[repr(transparent)] struct PointeeInAnotherTypeConstBlock<'a, #[pointee] T: ?Sized> { ptr: PointeeInConstConstBlock<'a, T, { struct UhOh<#[pointee] T>(T); 0 }> //~^ ERROR: the `#[pointee]` attribute may only be used on generic parameters } </ins> // However, reordering attributes should work nevertheless. #[repr(transparent)] #[derive(SmartPointer)]


Question:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.

LL | struct NoMaybeSized<'a, #[pointee] T> { |                                    ^ <ins> error: the `#[pointee]` attribute may only be used on generic parameters --> $DIR/deriving-smart-pointer-neg.rs:59:5 | LL |     #[pointee] |     ^^^^^^^^^^ error: the `#[pointee]` attribute may only be used on generic parameters --> $DIR/deriving-smart-pointer-neg.rs:66:74 | LL | struct PointeeInTypeConstBlock<'a, T: ?Sized = [u32; const { struct UhOh<#[pointee] T>(T); 10 }]> { |                                                                          ^^^^^^^^^^ error: the `#[pointee]` attribute may only be used on generic parameters --> $DIR/deriving-smart-pointer-neg.rs:76:34 | LL |     const V: u32 = { struct UhOh<#[pointee] T>(T); 10 }> |                                  ^^^^^^^^^^ error: the `#[pointee]` attribute may only be used on generic parameters --> $DIR/deriving-smart-pointer-neg.rs:85:56 | LL |     ptr: PointeeInConstConstBlock<'a, T, { struct UhOh<#[pointee] T>(T); 0 }> |                                                        ^^^^^^^^^^ </ins> error[E0392]: lifetime parameter `'a` is never used --> $DIR/deriving-smart-pointer-neg.rs:15:16 |


Question:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.

| = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` <del> error: aborting due to 12 previous errors </del> <ins> error: aborting due to 16 previous errors </ins> For more information about this error, try `rustc --explain E0392`.


Question: <!-- 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</detailsthis was at the end of the error <pi have put a comment in the code where the problematic line is, the problem could be caused by async trait object method in ResourceLoader::startloading<bri am using asynctrait crate<brhere is the library code that the problematic code uses<brthe ResourceLoader trait is at the end </prustc-ice-2024-08-02T150352-!

for debug_info in body.var_debug_info.iter_mut() { if let VarDebugInfoContents::Place(place) = &mut debug_info.value { let mut new_projections: Option<Vec<_>> = None; <del> let mut last_deref = 0; for (i, (base, elem)) in place.iter_projections().enumerate() { </del> <ins> for (base, elem) in place.iter_projections() { </ins> let base_ty = base.ty(&body.local_decls, tcx).ty; if elem == PlaceElem::Deref && base_ty.is_box() { <del> let new_projections = new_projections.get_or_insert_default(); </del> <ins> // Clone the projections before us, since now we need to mutate them. let new_projections = new_projections.get_or_insert_with(|| base.projection.to_vec()); </ins> let (unique_ty, nonnull_ty, ptr_ty) = build_ptr_tys(tcx, base_ty.boxed_ty(), unique_did, nonnull_did); <del> new_projections.extend_from_slice(&base.projection[last_deref..]); </del> new_projections.extend_from_slice(&build_projection( unique_ty, nonnull_ty, ptr_ty, )); new_projections.push(PlaceElem::Deref); <del> last_deref = i; </del> <ins> } else if let Some(new_projections) = new_projections.as_mut() { // Keep building up our projections list once we've started it. new_projections.push(elem); </ins> } } <del> if let Some(mut new_projections) = new_projections { new_projections.extend_from_slice(&place.projection[last_deref..]); </del> <ins> // Store the mutated projections if we actually changed something. if let Some(new_projections) = new_projections { </ins> place.projection = tcx.mk_place_elems(&new_projections); } }


Question: <!-- 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</detailsthis was at the end of the error <pi have put a comment in the code where the problematic line is, the problem could be caused by async trait object method in ResourceLoader::startloading<bri am using asynctrait crate<brhere is the library code that the problematic code uses<brthe ResourceLoader trait is at the end </prustc-ice-2024-08-02T150352-!

<ins> - // MIR for `pointee` before ElaborateBoxDerefs + // MIR for `pointee` after ElaborateBoxDerefs fn pointee(_1: Box<i32>) -> () { -     debug foo => (*_1); +     debug foo => (*(((_1.0: std::ptr::Unique<i32>).0: std::ptr::NonNull<i32>).0: *const i32)); let mut _0: (); bb0: { return; } } </ins>


Question: <!-- 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</detailsthis was at the end of the error <pi have put a comment in the code where the problematic line is, the problem could be caused by async trait object method in ResourceLoader::startloading<bri am using asynctrait crate<brhere is the library code that the problematic code uses<brthe ResourceLoader trait is at the end </prustc-ice-2024-08-02T150352-!

<ins> // skip-filecheck //@ test-mir-pass: ElaborateBoxDerefs #![feature(custom_mir, core_intrinsics)] extern crate core; use core::intrinsics::mir::*; // EMIT_MIR elaborate_box_deref_in_debuginfo.pointee.ElaborateBoxDerefs.diff #[custom_mir(dialect = "built")] fn pointee(opt: Box<i32>) { mir!( debug foo => *opt; { Return() } ) } fn main() {} </ins>


Question: <!-- 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</detailsthis was at the end of the error <pi have put a comment in the code where the problematic line is, the problem could be caused by async trait object method in ResourceLoader::startloading<bri am using asynctrait crate<brhere is the library code that the problematic code uses<brthe ResourceLoader trait is at the end </prustc-ice-2024-08-02T150352-!

<ins> //@ aux-build:block-on.rs //@ edition:2021 //@ run-pass #![feature(async_closure)] extern crate block_on; pub trait Trait { fn callback(&mut self); } impl Trait for (i32,) { fn callback(&mut self) { println!("hi {}", self.0); self.0 += 1; } } async fn call_once(f: impl async FnOnce()) { f().await; } async fn run(mut loader: Box<dyn Trait>) { let f = async move || { loader.callback(); loader.callback(); }; call_once(f).await; } fn main() { block_on::block_on(async { run(Box::new((42,))).await; }); } </ins>