Question:
<!-- ICE: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seeeems to bisect to :thinking: cc
Thanks Will take a look. claim
Reduced further:
the original (none reduced) one still ices :sweat_smile:
From what I can tell, it seems to have been fixed : Looks like I'm missing something
I have now opened PR to test the below original reproducer:
Sorry for causing the issue to be closed via the PR merge without asking you first. If you still believe the ICE is not fixed please reopen it.

<ins> error[E0425]: cannot find value `bar` in this scope --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:30 | LL | trait Trait<const N: Trait = bar> { |                              ^^^ not found in this scope warning: trait objects without an explicit `dyn` are deprecated --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:22 | LL | trait Trait<const N: Trait = bar> { |                      ^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> = note: `#[warn(bare_trait_objects)]` on by default help: if this is an object-safe trait, use `dyn` | LL | trait Trait<const N: dyn Trait = bar> { |                      +++ error[E0391]: cycle detected when computing type of `Trait::N` --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:22 | LL | trait Trait<const N: Trait = bar> { |                      ^^^^^ | = note: ...which immediately requires computing type of `Trait::N` again note: cycle used when computing explicit predicates of trait `Trait` --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:1 | LL | trait Trait<const N: Trait = bar> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information error[E0391]: cycle detected when computing type of `Trait::N` --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:13 | LL | trait Trait<const N: Trait = bar> { |             ^^^^^^^^^^^^^^^^^^^^ | = note: ...which immediately requires computing type of `Trait::N` again note: cycle used when computing explicit predicates of trait `Trait` --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:1 | LL | trait Trait<const N: Trait = bar> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information error: `(dyn Trait<{const error}> + 'static)` is forbidden as the type of a const generic parameter --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:22 | LL | trait Trait<const N: Trait = bar> { |                      ^^^^^ | = note: the only supported types are integers, `bool` and `char` error: aborting due to 4 previous errors; 1 warning emitted Some errors have detailed explanations: E0391, E0425. For more information about an error, try `rustc --explain E0391`. </ins>


Question:
<!-- ICE: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seeeems to bisect to :thinking: cc
Thanks Will take a look. claim
Reduced further:
the original (none reduced) one still ices :sweat_smile:
From what I can tell, it seems to have been fixed : Looks like I'm missing something
I have now opened PR to test the below original reproducer:
Sorry for causing the issue to be closed via the PR merge without asking you first. If you still believe the ICE is not fixed please reopen it.

trait Trait<const N: Trait = bar> { <del> //~^ ERROR cannot find value `bar` in this scope //~| ERROR cycle detected when computing type of `Trait::N` //~| ERROR cycle detected when computing type of `Trait::N` //~| ERROR `(dyn Trait<{const error}> + 'static)` is forbidden as the type of a const generic parameter //~| WARN trait objects without an explicit `dyn` are deprecated //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! fn fnc(&self) { </del> <ins> //~^ ERROR cannot find value `bar` in this scope //~| ERROR cycle detected when computing type of `Trait::N` //~| ERROR cycle detected when computing type of `Trait::N` //~| ERROR the trait `Trait` cannot be made into an object //~| ERROR the trait `Trait` cannot be made into an object //~| ERROR the trait `Trait` cannot be made into an object //~| ERROR `(dyn Trait<{const error}> + 'static)` is forbidden as the type of a const generic parameter //~| WARN trait objects without an explicit `dyn` are deprecated [bare_trait_objects] //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! //~| WARN trait objects without an explicit `dyn` are deprecated [bare_trait_objects] //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! fn fnc<const N: Trait = u32>(&self) -> Trait { //~^ ERROR the name `N` is already used for a generic parameter in this item's generic parameters //~| ERROR expected value, found builtin type `u32` //~| ERROR defaults for const parameters are only allowed in `struct`, `enum`, `type`, or `trait` definitions //~| ERROR associated item referring to unboxed trait object for its own trait //~| ERROR the trait `Trait` cannot be made into an object //~| ERROR `(dyn Trait<{const error}> + 'static)` is forbidden as the type of a const generic parameter //~| WARN trait objects without an explicit `dyn` are deprecated [bare_trait_objects] //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! //~| WARN trait objects without an explicit `dyn` are deprecated [bare_trait_objects] //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! //~| WARN trait objects without an explicit `dyn` are deprecated [bare_trait_objects] //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! bar //~^ ERROR cannot find value `bar` in this scope </ins> } }


Question:
<!-- ICE: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seeeems to bisect to :thinking: cc
Thanks Will take a look. claim
Reduced further:
the original (none reduced) one still ices :sweat_smile:
From what I can tell, it seems to have been fixed : Looks like I'm missing something
I have now opened PR to test the below original reproducer:
Sorry for causing the issue to be closed via the PR merge without asking you first. If you still believe the ICE is not fixed please reopen it.

<ins> error[E0403]: the name `N` is already used for a generic parameter in this item's generic parameters --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:18 | LL | trait Trait<const N: Trait = bar> { |                   - first use of `N` ... LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |                  ^ already used </ins> error[E0425]: cannot find value `bar` in this scope --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:30 | LL | trait Trait<const N: Trait = bar> { |                              ^^^ not found in this scope <ins> error[E0423]: expected value, found builtin type `u32` --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:29 | LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |                             ^^^ not a value error[E0425]: cannot find value `bar` in this scope --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:26:9 | LL |         bar |         ^^^ not found in this scope </ins> warning: trait objects without an explicit `dyn` are deprecated --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:22 |


Question:
<!-- ICE: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seeeems to bisect to :thinking: cc
Thanks Will take a look. claim
Reduced further:
the original (none reduced) one still ices :sweat_smile:
From what I can tell, it seems to have been fixed : Looks like I'm missing something
I have now opened PR to test the below original reproducer:
Sorry for causing the issue to be closed via the PR merge without asking you first. If you still believe the ICE is not fixed please reopen it.

| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information <ins> error: defaults for const parameters are only allowed in `struct`, `enum`, `type`, or `trait` definitions --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:12 | LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |            ^^^^^^^^^^^^^^^^^^^^ warning: trait objects without an explicit `dyn` are deprecated --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:21 | LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |                     ^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> help: if this is an object-safe trait, use `dyn` | LL |     fn fnc<const N: dyn Trait = u32>(&self) -> Trait { |                     +++ warning: trait objects without an explicit `dyn` are deprecated --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:44 | LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |                                            ^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> help: if this is an object-safe trait, use `dyn` | LL |     fn fnc<const N: Trait = u32>(&self) -> dyn Trait { |                                            +++ warning: trait objects without an explicit `dyn` are deprecated --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:22 | LL | trait Trait<const N: Trait = bar> { |                      ^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` help: if this is an object-safe trait, use `dyn` | LL | trait Trait<const N: dyn Trait = bar> { |                      +++ error[E0038]: the trait `Trait` cannot be made into an object --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:22 | LL | trait Trait<const N: Trait = bar> { |                      ^^^^^ `Trait` cannot be made into an object | note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety> --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:8 | LL | trait Trait<const N: Trait = bar> { |       ----- this trait cannot be made into an object... ... LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |        ^^^ ...because method `fnc` has generic type parameters = help: consider moving `fnc` to another trait error[E0038]: the trait `Trait` cannot be made into an object --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:13 | LL | trait Trait<const N: Trait = bar> { |             ^^^^^^^^^^^^^^^^^^^^ `Trait` cannot be made into an object | note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety> --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:8 | LL | trait Trait<const N: Trait = bar> { |       ----- this trait cannot be made into an object... ... LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |        ^^^ ...because method `fnc` has generic type parameters = help: consider moving `fnc` to another trait </ins> error: `(dyn Trait<{const error}> + 'static)` is forbidden as the type of a const generic parameter --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:22 |


Question:
<!-- ICE: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seeeems to bisect to :thinking: cc
Thanks Will take a look. claim
Reduced further:
the original (none reduced) one still ices :sweat_smile:
From what I can tell, it seems to have been fixed : Looks like I'm missing something
I have now opened PR to test the below original reproducer:
Sorry for causing the issue to be closed via the PR merge without asking you first. If you still believe the ICE is not fixed please reopen it.

| = note: the only supported types are integers, `bool` and `char` <del> error: aborting due to 4 previous errors; 1 warning emitted </del> <ins> error: associated item referring to unboxed trait object for its own trait --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:44 | LL | trait Trait<const N: Trait = bar> { |       ----- in this trait ... LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |                                            ^^^^^ | help: you might have meant to use `Self` to refer to the implementing type | LL |     fn fnc<const N: Trait = u32>(&self) -> Self { |                                            ~~~~ warning: trait objects without an explicit `dyn` are deprecated --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:21 | LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |                     ^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` help: if this is an object-safe trait, use `dyn` | LL |     fn fnc<const N: dyn Trait = u32>(&self) -> Trait { |                     +++ error[E0038]: the trait `Trait` cannot be made into an object --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:21 | LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |                     ^^^^^ `Trait` cannot be made into an object | note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety> --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:8 | LL | trait Trait<const N: Trait = bar> { |       ----- this trait cannot be made into an object... ... LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |        ^^^ ...because method `fnc` has generic type parameters = help: consider moving `fnc` to another trait error[E0038]: the trait `Trait` cannot be made into an object --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:1:13 | LL | trait Trait<const N: Trait = bar> { |             ^^^^^^^^^^^^^^^^^^^^ `Trait` cannot be made into an object | note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety> --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:8 | LL | trait Trait<const N: Trait = bar> { |       ----- this trait cannot be made into an object... ... LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |        ^^^ ...because method `fnc` has generic type parameters = help: consider moving `fnc` to another trait = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error: `(dyn Trait<{const error}> + 'static)` is forbidden as the type of a const generic parameter --> $DIR/ice-hir-wf-check-anon-const-issue-122199.rs:13:21 | LL |     fn fnc<const N: Trait = u32>(&self) -> Trait { |                     ^^^^^ | = note: the only supported types are integers, `bool` and `char` error: aborting due to 14 previous errors; 5 warnings emitted </ins> <del> Some errors have detailed explanations: E0391, E0425. For more information about an error, try `rustc --explain E0391`. </del> <ins> Some errors have detailed explanations: E0038, E0391, E0403, E0423, E0425. For more information about an error, try `rustc --explain E0038`. </ins>


Question:
The compiler allows this code when it shouldn't The following code is buggy: Invalid string contains, as the name suggests, an invalid string; sometimes I get a string filled with , sometimes just garbage, and usually it will eventually assert that the string contains invalid characters. It appears that the first gets dropped when the second one is assigned? Either the first is supposed to be dropped as happens now, and the borrow checker should forbid this code (since the old no longer exists, cannot have a lifetime), or it should let the first live until the end of the current scope, and make the above work.
What platform are you running this on? This code compiles and prints for me on OSX
I hadn't actually tried in my own rustc, I created the minimized version on rusti: Inspired by an actual bug that I got after trying to read some stuff from a file. It seems what I posted originally does actually compile and work properly on my system as well, I guess I should have tested that... I'll try and find and find a minimized example tomorrow.
is getting old at this point, and I suspect that this was fixed by
This one asserts (sometimes, it's random) for real on my system, most recent build of master (debian 64-bit, rustc 0.10-pre 2014-02-12 14:51:48 -0800) Assuming the executable is named bug: run with Removing the line that says gives me the output: Otherwise it appears random, usually asserting:
Quite plausibly due to , though I haven't dug in in detail.
It seems the bug persists even without the shadowing so perhaps this is related to , except for the 'match' part?
It appears that we allow this code to compile: Nominating, that's bad.
Any suggestions for a better name for this issue? The current name is misleading. Perhaps something along the lines of "Stale pointers can be created in safe code"?
Updated title and description
cc me
cc
Interestingly enough, the compiler rejects this code: It appears that the type ascription is throwing off the compiler?
Another example taken from
0, P-backcompat-lang
The compiler correctly rejects:
cc me
has taken a major detour to fix other two more fundamental bugs first. On top of that fix, the root cause of this bug is also becoming clearer. Case 1: Case 2: Case 3: The difference here is that the RHS is directly assignable to LHS in case 1 but not in case 2 + 3 so takes different code paths. And in latter two cases, there's bug in which upstream and downstream code inside disagree with the order of two parameters so two regions are merged incorrectly. The fix is rather simple. But the variance inference adds another twist to case 3. The result of variance inference can be used to do type parameter substitution, which is not enabled yet. The net effect is two negatives become positive; the current rejects that too.It did compile on top of , which in itself is incorrect. So I guess the fix for this bug must wait for the PR to land.

use middle::freevars; use middle::pat_util; use middle::ty; <del> use middle::typeck::MethodCall; </del> <ins> use middle::typeck::{MethodCall, MethodObject, MethodOrigin, MethodParam}; use middle::typeck::{MethodStatic}; </ins> use middle::typeck; <del> use syntax::ast; use syntax::codemap::{Span}; </del> use util::ppaux::Repr; use std::gc::Gc; <ins> use syntax::ast; use syntax::codemap::Span; </ins> /////////////////////////////////////////////////////////////////////////// // The Delegate trait


Question:
The compiler allows this code when it shouldn't The following code is buggy: Invalid string contains, as the name suggests, an invalid string; sometimes I get a string filled with , sometimes just garbage, and usually it will eventually assert that the string contains invalid characters. It appears that the first gets dropped when the second one is assigned? Either the first is supposed to be dropped as happens now, and the borrow checker should forbid this code (since the old no longer exists, cannot have a lifetime), or it should let the first live until the end of the current scope, and make the above work.
What platform are you running this on? This code compiles and prints for me on OSX
I hadn't actually tried in my own rustc, I created the minimized version on rusti: Inspired by an actual bug that I got after trying to read some stuff from a file. It seems what I posted originally does actually compile and work properly on my system as well, I guess I should have tested that... I'll try and find and find a minimized example tomorrow.
is getting old at this point, and I suspect that this was fixed by
This one asserts (sometimes, it's random) for real on my system, most recent build of master (debian 64-bit, rustc 0.10-pre 2014-02-12 14:51:48 -0800) Assuming the executable is named bug: run with Removing the line that says gives me the output: Otherwise it appears random, usually asserting:
Quite plausibly due to , though I haven't dug in in detail.
It seems the bug persists even without the shadowing so perhaps this is related to , except for the 'match' part?
It appears that we allow this code to compile: Nominating, that's bad.
Any suggestions for a better name for this issue? The current name is misleading. Perhaps something along the lines of "Stale pointers can be created in safe code"?
Updated title and description
cc me
cc
Interestingly enough, the compiler rejects this code: It appears that the type ascription is throwing off the compiler?
Another example taken from
0, P-backcompat-lang
The compiler correctly rejects:
cc me
has taken a major detour to fix other two more fundamental bugs first. On top of that fix, the root cause of this bug is also becoming clearer. Case 1: Case 2: Case 3: The difference here is that the RHS is directly assignable to LHS in case 1 but not in case 2 + 3 so takes different code paths. And in latter two cases, there's bug in which upstream and downstream code inside disagree with the order of two parameters so two regions are merged incorrectly. The fix is rather simple. But the variance inference adds another twist to case 3. The result of variance inference can be used to do type parameter substitution, which is not enabled yet. The net effect is two negatives become positive; the current rejects that too.It did compile on top of , which in itself is incorrect. So I guess the fix for this bug must wait for the PR to land.

WriteAndRead, // x += y } <ins> enum OverloadedCallType { FnOverloadedCall, FnMutOverloadedCall, FnOnceOverloadedCall, } impl OverloadedCallType { fn from_trait_id(tcx: &ty::ctxt, trait_id: ast::DefId) -> OverloadedCallType { for &(maybe_function_trait, overloaded_call_type) in [ (tcx.lang_items.fn_once_trait(), FnOnceOverloadedCall), (tcx.lang_items.fn_mut_trait(), FnMutOverloadedCall), (tcx.lang_items.fn_trait(), FnOverloadedCall) ].iter() { match maybe_function_trait { Some(function_trait) if function_trait == trait_id => { return overloaded_call_type } _ => continue, } } tcx.sess.bug("overloaded call didn't map to known function trait") } fn from_method_id(tcx: &ty::ctxt, method_id: ast::DefId) -> OverloadedCallType { let method_descriptor = match tcx.methods.borrow_mut().find(&method_id) { None => { tcx.sess.bug("overloaded call method wasn't in method  map") } Some(ref method_descriptor) => (*method_descriptor).clone(), }; let impl_id = match method_descriptor.container { ty::TraitContainer(_) => { tcx.sess.bug("statically resolved overloaded call method  belonged to a trait?!") } ty::ImplContainer(impl_id) => impl_id, }; let trait_ref = match ty::impl_trait_ref(tcx, impl_id) { None => { tcx.sess.bug("statically resolved overloaded call impl  didn't implement a trait?!") } Some(ref trait_ref) => (*trait_ref).clone(), }; OverloadedCallType::from_trait_id(tcx, trait_ref.def_id) } fn from_method_origin(tcx: &ty::ctxt, origin: &MethodOrigin) -> OverloadedCallType { match *origin { MethodStatic(def_id) => { OverloadedCallType::from_method_id(tcx, def_id) } MethodParam(ref method_param) => { OverloadedCallType::from_trait_id(tcx, method_param.trait_id) } MethodObject(ref method_object) => { OverloadedCallType::from_trait_id(tcx, method_object.trait_id) } } } } </ins> /////////////////////////////////////////////////////////////////////////// // The ExprUseVisitor type //


Question:
The compiler allows this code when it shouldn't The following code is buggy: Invalid string contains, as the name suggests, an invalid string; sometimes I get a string filled with , sometimes just garbage, and usually it will eventually assert that the string contains invalid characters. It appears that the first gets dropped when the second one is assigned? Either the first is supposed to be dropped as happens now, and the borrow checker should forbid this code (since the old no longer exists, cannot have a lifetime), or it should let the first live until the end of the current scope, and make the above work.
What platform are you running this on? This code compiles and prints for me on OSX
I hadn't actually tried in my own rustc, I created the minimized version on rusti: Inspired by an actual bug that I got after trying to read some stuff from a file. It seems what I posted originally does actually compile and work properly on my system as well, I guess I should have tested that... I'll try and find and find a minimized example tomorrow.
is getting old at this point, and I suspect that this was fixed by
This one asserts (sometimes, it's random) for real on my system, most recent build of master (debian 64-bit, rustc 0.10-pre 2014-02-12 14:51:48 -0800) Assuming the executable is named bug: run with Removing the line that says gives me the output: Otherwise it appears random, usually asserting:
Quite plausibly due to , though I haven't dug in in detail.
It seems the bug persists even without the shadowing so perhaps this is related to , except for the 'match' part?
It appears that we allow this code to compile: Nominating, that's bad.
Any suggestions for a better name for this issue? The current name is misleading. Perhaps something along the lines of "Stale pointers can be created in safe code"?
Updated title and description
cc me
cc
Interestingly enough, the compiler rejects this code: It appears that the type ascription is throwing off the compiler?
Another example taken from
0, P-backcompat-lang
The compiler correctly rejects:
cc me
has taken a major detour to fix other two more fundamental bugs first. On top of that fix, the root cause of this bug is also becoming clearer. Case 1: Case 2: Case 3: The difference here is that the RHS is directly assignable to LHS in case 1 but not in case 2 + 3 so takes different code paths. And in latter two cases, there's bug in which upstream and downstream code inside disagree with the order of two parameters so two regions are merged incorrectly. The fix is rather simple. But the variance inference adds another twist to case 3. The result of variance inference can be used to do type parameter substitution, which is not enabled yet. The net effect is two negatives become positive; the current rejects that too.It did compile on top of , which in itself is incorrect. So I guess the fix for this bug must wait for the PR to land.

} } _ => { <del> match self.tcx() .method_map .borrow() .find(&MethodCall::expr(call.id)) { Some(_) => { // FIXME(#14774, pcwalton): Implement this. </del> <ins> let overloaded_call_type = match self.tcx() .method_map .borrow() .find(&MethodCall::expr(call.id)) { Some(ref method_callee) => { OverloadedCallType::from_method_origin( self.tcx(), &method_callee.origin) </ins> } None => { self.tcx().sess.span_bug( callee.span, format!("unexpected callee type {}", <del> callee_ty.repr(self.tcx())).as_slice()); </del> <ins> callee_ty.repr(self.tcx())).as_slice()) } }; match overloaded_call_type { FnMutOverloadedCall => { self.borrow_expr(callee, ty::ReScope(call.id), ty::MutBorrow, ClosureInvocation); } FnOverloadedCall => { self.borrow_expr(callee, ty::ReScope(call.id), ty::ImmBorrow, ClosureInvocation); </ins> } <ins> FnOnceOverloadedCall => self.consume_expr(callee), </ins> } } }


Question:
The compiler allows this code when it shouldn't The following code is buggy: Invalid string contains, as the name suggests, an invalid string; sometimes I get a string filled with , sometimes just garbage, and usually it will eventually assert that the string contains invalid characters. It appears that the first gets dropped when the second one is assigned? Either the first is supposed to be dropped as happens now, and the borrow checker should forbid this code (since the old no longer exists, cannot have a lifetime), or it should let the first live until the end of the current scope, and make the above work.
What platform are you running this on? This code compiles and prints for me on OSX
I hadn't actually tried in my own rustc, I created the minimized version on rusti: Inspired by an actual bug that I got after trying to read some stuff from a file. It seems what I posted originally does actually compile and work properly on my system as well, I guess I should have tested that... I'll try and find and find a minimized example tomorrow.
is getting old at this point, and I suspect that this was fixed by
This one asserts (sometimes, it's random) for real on my system, most recent build of master (debian 64-bit, rustc 0.10-pre 2014-02-12 14:51:48 -0800) Assuming the executable is named bug: run with Removing the line that says gives me the output: Otherwise it appears random, usually asserting:
Quite plausibly due to , though I haven't dug in in detail.
It seems the bug persists even without the shadowing so perhaps this is related to , except for the 'match' part?
It appears that we allow this code to compile: Nominating, that's bad.
Any suggestions for a better name for this issue? The current name is misleading. Perhaps something along the lines of "Stale pointers can be created in safe code"?
Updated title and description
cc me
cc
Interestingly enough, the compiler rejects this code: It appears that the type ascription is throwing off the compiler?
Another example taken from
0, P-backcompat-lang
The compiler correctly rejects:
cc me
has taken a major detour to fix other two more fundamental bugs first. On top of that fix, the root cause of this bug is also becoming clearer. Case 1: Case 2: Case 3: The difference here is that the RHS is directly assignable to LHS in case 1 but not in case 2 + 3 so takes different code paths. And in latter two cases, there's bug in which upstream and downstream code inside disagree with the order of two parameters so two regions are merged incorrectly. The fix is rather simple. But the variance inference adds another twist to case 3. The result of variance inference can be used to do type parameter substitution, which is not enabled yet. The net effect is two negatives become positive; the current rejects that too.It did compile on top of , which in itself is incorrect. So I guess the fix for this bug must wait for the PR to land.

<ins> // Copyright 2012 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(overloaded_calls)] use std::ops::{Fn, FnMut, FnOnce}; struct SFn { x: int, y: int, } impl Fn<(int,),int> for SFn { fn call(&self, (z,): (int,)) -> int { self.x * self.y * z } } struct SFnMut { x: int, y: int, } impl FnMut<(int,),int> for SFnMut { fn call_mut(&mut self, (z,): (int,)) -> int { self.x * self.y * z } } struct SFnOnce { x: String, } impl FnOnce<(String,),uint> for SFnOnce { fn call_once(self, (z,): (String,)) -> uint { self.x.len() + z.len() } } fn f() { let mut s = SFn { x: 1, y: 2, }; let sp = &mut s; s(3);   //~ ERROR cannot borrow `s` as immutable because it is also borrowed as mutable //~^ ERROR cannot borrow `s` as immutable because it is also borrowed as mutable } fn g() { let s = SFnMut { x: 1, y: 2, }; s(3);   //~ ERROR cannot borrow immutable local variable `s` as mutable } fn h() { let s = SFnOnce { x: "hello".to_string(), }; s(" world".to_string()); s(" world".to_string());    //~ ERROR use of moved value: `s` } fn main() {} </ins>


Question:
When compiling my feature and is included I got the attached ICE. The following is the unstable configuration is the repository this occurs on. I will get a minimal verifiable example setup shortly. <details<summaryBacktrace</summary<p</p</details
Here is the full ICE output:
Turns out I was missing in my deny list. Not sure if that should be an ICE or not, feel free to close if that is expected behavior. This wasn't a fix, the behavior still happened.
Does this specifically only happen with clippy, or does this ICE also happen with a regular /? The backtrace and the fact that these are all rustc lints/features makes me think it's a bug in the compiler
and both produce the same ICE.
Moving to rust-lang/rust in that case, since it sounds like fixing this requires changes in the compiler and we can't do much about that on the clippy side
From what I can tell, MCVE is or, alternatively,
searched nightlies: from nightly-2024-01-01 to nightly-2024-03-12 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsProbably , cc
I filled to address this

pub UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES, Warn, "unrecognized or malformed diagnostic attribute", <del> @feature_gate = sym::diagnostic_namespace; </del> } declare_lint! {


Question:
When compiling my feature and is included I got the attached ICE. The following is the unstable configuration is the repository this occurs on. I will get a minimal verifiable example setup shortly. <details<summaryBacktrace</summary<p</p</details
Here is the full ICE output:
Turns out I was missing in my deny list. Not sure if that should be an ICE or not, feel free to close if that is expected behavior. This wasn't a fix, the behavior still happened.
Does this specifically only happen with clippy, or does this ICE also happen with a regular /? The backtrace and the fact that these are all rustc lints/features makes me think it's a bug in the compiler
and both produce the same ICE.
Moving to rust-lang/rust in that case, since it sounds like fixing this requires changes in the compiler and we can't do much about that on the clippy side
From what I can tell, MCVE is or, alternatively,
searched nightlies: from nightly-2024-01-01 to nightly-2024-03-12 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsProbably , cc
I filled to address this

<ins> #![deny(unknown_or_malformed_diagnostic_attributes)] #[diagnostic::unknown_attribute] //~^ERROR unknown diagnostic attribute struct Foo; fn main() {} </ins>


Question:
When compiling my feature and is included I got the attached ICE. The following is the unstable configuration is the repository this occurs on. I will get a minimal verifiable example setup shortly. <details<summaryBacktrace</summary<p</p</details
Here is the full ICE output:
Turns out I was missing in my deny list. Not sure if that should be an ICE or not, feel free to close if that is expected behavior. This wasn't a fix, the behavior still happened.
Does this specifically only happen with clippy, or does this ICE also happen with a regular /? The backtrace and the fact that these are all rustc lints/features makes me think it's a bug in the compiler
and both produce the same ICE.
Moving to rust-lang/rust in that case, since it sounds like fixing this requires changes in the compiler and we can't do much about that on the clippy side
From what I can tell, MCVE is or, alternatively,
searched nightlies: from nightly-2024-01-01 to nightly-2024-03-12 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsProbably , cc
I filled to address this

<ins> error: unknown diagnostic attribute --> $DIR/deny_malformed_attribute.rs:3:15 | LL | #[diagnostic::unknown_attribute] |               ^^^^^^^^^^^^^^^^^ | note: the lint level is defined here --> $DIR/deny_malformed_attribute.rs:1:9 | LL | #![deny(unknown_or_malformed_diagnostic_attributes)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- 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. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry

generics_of => { table } inferred_outlives_of => { table_defaulted_array } super_predicates_of => { table } <ins> implied_predicates_of => { table } </ins> type_of => { table } type_alias_is_lazy => { cdata.root.tables.type_alias_is_lazy.get(cdata, def_id.index) } variances_of => { table }


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: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- 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. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry

.map(|lazy| lazy.decode((cdata, tcx))) .process_decoded(tcx, || panic!("{def_id:?} does not have trait_impl_trait_tys"))) } <del> implied_predicates_of => { cdata .root .tables .implied_predicates_of .get(cdata, def_id.index) .map(|lazy| lazy.decode((cdata, tcx))) .unwrap_or_else(|| { debug_assert_eq!(tcx.def_kind(def_id), DefKind::Trait); tcx.super_predicates_of(def_id) }) } </del> associated_types_for_impl_traits_in_associated_fn => { table_defaulted_array }


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: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- 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. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry

if let DefKind::Trait = def_kind { record!(self.tables.trait_def[def_id] <- self.tcx.trait_def(def_id)); record!(self.tables.super_predicates_of[def_id] <- self.tcx.super_predicates_of(def_id)); <ins> record!(self.tables.implied_predicates_of[def_id] <- self.tcx.implied_predicates_of(def_id)); </ins> let module_children = self.tcx.module_children_local(local_id); record_array!(self.tables.module_children_non_reexports[def_id] <-


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: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- 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. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry

<ins> pub trait Bar: Super<SuperAssoc: Bound> {} pub trait Super { type SuperAssoc; } pub trait Bound {} </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: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- 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. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry

<ins> //@ aux-build:implied-predicates.rs //@ check-pass extern crate implied_predicates; use implied_predicates::Bar; fn bar<B: Bar>() {} 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. --(reduced) (original) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongCode</strong</summary<p</p</details<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- The in closed issue is same as the .
Regression in The PR introducing the regression in this rollup is : Provide structured suggestion for searched nightlies: from nightly-2024-03-16 to nightly-2024-03-23 regressed nightly: nightly-2024-03-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This was caused by the introduction of which has no parent. This seems like a gun aimed squarely at the foot of any user of or . I believe we need to audit all existing uses of these (if you haven't done that already).

<ins> // Don't panic when iterating through the `hir::Map::parent_iter` of an RPITIT. pub trait Foo { fn demo() -> impl Foo //~^ ERROR the trait bound `String: Copy` is not satisfied where String: Copy; //~^ ERROR the trait bound `String: Copy` is not satisfied } 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. --(reduced) (original) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongCode</strong</summary<p</p</details<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- The in closed issue is same as the .
Regression in The PR introducing the regression in this rollup is : Provide structured suggestion for searched nightlies: from nightly-2024-03-16 to nightly-2024-03-23 regressed nightly: nightly-2024-03-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This was caused by the introduction of which has no parent. This seems like a gun aimed squarely at the foot of any user of or . I believe we need to audit all existing uses of these (if you haven't done that already).

<ins> error[E0277]: the trait bound `String: Copy` is not satisfied --> $DIR/synthetic-hir-has-parent.rs:7:9 | LL |         String: Copy; |         ^^^^^^^^^^^^ the trait `Copy` is not implemented for `String` | = help: see issue #48214 help: add `#![feature(trivial_bounds)]` to the crate attributes to enable | LL + #![feature(trivial_bounds)] | error[E0277]: the trait bound `String: Copy` is not satisfied --> $DIR/synthetic-hir-has-parent.rs:4:18 | LL |     fn demo() -> impl Foo |                  ^^^^^^^^ the trait `Copy` is not implemented for `String` | = help: see issue #48214 help: add `#![feature(trivial_bounds)]` to the crate attributes to enable | LL + #![feature(trivial_bounds)] | error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)', 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to cc

pat: &'tcx hir::Pat<'tcx>, ty: Ty<'tcx>, ) { <del> struct V<'tcx> { tcx: TyCtxt<'tcx>, </del> <ins> struct V { </ins> pat_hir_ids: Vec<hir::HirId>, } <del> impl<'tcx> Visitor<'tcx> for V<'tcx> { type NestedFilter = rustc_middle::hir::nested_filter::All; fn nested_visit_map(&mut self) -> Self::Map { self.tcx.hir() } </del> <ins> impl<'tcx> Visitor<'tcx> for V { </ins> fn visit_pat(&mut self, p: &'tcx hir::Pat<'tcx>) { self.pat_hir_ids.push(p.hir_id); hir::intravisit::walk_pat(self, p);


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)', 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to cc

let err = Ty::new_error(self.tcx, guar); self.write_ty(hir_id, err); self.write_ty(pat.hir_id, err); <del> let mut visitor = V { tcx: self.tcx, pat_hir_ids: vec![] }; </del> <ins> let mut visitor = V { pat_hir_ids: vec![] }; </ins> hir::intravisit::walk_pat(&mut visitor, pat); // Mark all the subpatterns as `{type error}` as well. This allows errors for specific // subpatterns to be silenced.


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)', 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to cc

<ins> fn main() { let str::<{fn str() { let str::T>>::as_bytes; }}, T>::as_bytes; //~^ ERROR expected a pattern, found an expression //~| ERROR cannot find type `T` in this scope //~| ERROR type and const arguments are not allowed on builtin type `str` //~| ERROR expected unit struct, unit variant or constant, found associated function `str<, T>::as_bytes` } </ins>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)', 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to cc

<ins> error: expected a pattern, found an expression --> $DIR/ensure-overriding-bindings-in-pattern-with-ty-err-doesnt-ice.rs:2:31 | LL |     let str::<{fn str() { let str::T>>::as_bytes; }}, T>::as_bytes; |                               ^^^^^^^^^^^^^^^^^^ arbitrary expressions are not allowed in patterns error[E0412]: cannot find type `T` in this scope --> $DIR/ensure-overriding-bindings-in-pattern-with-ty-err-doesnt-ice.rs:2:55 | LL |     let str::<{fn str() { let str::T>>::as_bytes; }}, T>::as_bytes; |                                                       ^ not found in this scope error[E0109]: type and const arguments are not allowed on builtin type `str` --> $DIR/ensure-overriding-bindings-in-pattern-with-ty-err-doesnt-ice.rs:2:15 | LL |     let str::<{fn str() { let str::T>>::as_bytes; }}, T>::as_bytes; |         ---   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^ type and const arguments not allowed |         | |         not allowed on builtin type `str` | help: primitive type `str` doesn't have generic parameters | LL -     let str::<{fn str() { let str::T>>::as_bytes; }}, T>::as_bytes; LL +     let str::as_bytes; | error[E0533]: expected unit struct, unit variant or constant, found associated function `str<, T>::as_bytes` --> $DIR/ensure-overriding-bindings-in-pattern-with-ty-err-doesnt-ice.rs:2:9 | LL |     let str::<{fn str() { let str::T>>::as_bytes; }}, T>::as_bytes; |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not a unit struct, unit variant or constant error: aborting due to 4 previous errors Some errors have detailed explanations: E0109, E0412, E0533. For more information about an error, try `rustc --explain E0109`. </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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.

impl_clone! { usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 <del> f32 f64 </del> <ins> f16 f32 f64 f128 </ins> bool char }


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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.

} partial_eq_impl! { <del> bool char usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 f32 f64 </del> <ins> bool char usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 f16 f32 f64 f128 </ins> } macro_rules! eq_impl {


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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.

} } <del> partial_ord_impl! { f32 f64 } </del> <ins> partial_ord_impl! { f16 f32 f64 f128 } </ins> macro_rules! ord_impl { ($($t:ty)*) => ($(


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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.

default_impl! { i64, 0, "Returns the default value of `0`" } default_impl! { i128, 0, "Returns the default value of `0`" } <ins> #[cfg(not(bootstrap))] default_impl! { f16, 0.0f16, "Returns the default value of `0.0`" } </ins> default_impl! { f32, 0.0f32, "Returns the default value of `0.0`" } default_impl! { f64, 0.0f64, "Returns the default value of `0.0`" } <ins> #[cfg(not(bootstrap))] default_impl! { f128, 0.0f128, "Returns the default value of `0.0`" } </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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.

#![feature(doc_notable_trait)] #![feature(effects)] #![feature(extern_types)] <ins> #![feature(f128)] #![feature(f16)] </ins> #![feature(freeze_impls)] #![feature(fundamental)] #![feature(generic_arg_infer)]


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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.

Copy for usize, u8, u16, u32, u64, u128, isize, i8, i16, i32, i64, i128, <del> f32, f64, </del> <ins> f16, f32, f64, f128, </ins> bool, char, {T: ?Sized} *const T, {T: ?Sized} *mut T,


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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.

| = help: the trait `PartialEq<Foo>` is not implemented for `&&{integer}` = help: the following other types implement trait `PartialEq<Rhs>`: <ins> f128 f16 </ins> f32 f64 i128 i16 i32 i64 <del> i8 isize and 6 others </del> <ins> and 8 others </ins> error[E0369]: binary operation `==` cannot be applied to type `Foo` --> $DIR/binary-op-suggest-deref.rs:60:13


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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.

| = help: the trait `PartialOrd<String>` is not implemented for `{integer}` = help: the following other types implement trait `PartialOrd<Rhs>`: <ins> f128 f16 </ins> f32 f64 i128 i16 i32 i64 <del> i8 isize and 6 others </del> <ins> and 8 others </ins> error[E0277]: can't compare `{integer}` with `Result<{integer}, _>` --> $DIR/binops.rs:7:7


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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.

| = help: the trait `PartialEq<Result<{integer}, _>>` is not implemented for `{integer}` = help: the following other types implement trait `PartialEq<Rhs>`: <ins> f128 f16 </ins> f32 f64 i128 i16 i32 i64 <del> i8 isize and 6 others </del> <ins> and 8 others </ins> error: aborting due to 6 previous errors


Question:
<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced

let expn_data = prefix_span.ctxt().outer_expn_data(); if expn_data.edition >= Edition::Edition2021 { <del> let mut silence = false; </del> // In Rust 2021, this is a hard error. let sugg = if prefix == "rb" { Some(errors::UnknownPrefixSugg::UseBr(prefix_span))


Question:
<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced

if self.cursor.first() == ''' && let Some(start) = self.last_lifetime && self.cursor.third() != ''' <ins> && let end = self.mk_sp(self.pos, self.pos + BytePos(1)) && !self.psess.source_map().is_multiline(start.until(end)) </ins> { <del> // An "unclosed `char`" error will be emitted already, silence redundant error. silence = true; Some(errors::UnknownPrefixSugg::MeantStr { start, end: self.mk_sp(self.pos, self.pos + BytePos(1)), }) </del> <ins> // FIXME: An "unclosed `char`" error will be emitted already in some cases, // but it's hard to silence this error while not also silencing important cases // too. We should use the error stashing machinery instead. Some(errors::UnknownPrefixSugg::MeantStr { start, end }) </ins> } else { Some(errors::UnknownPrefixSugg::Whitespace(prefix_span.shrink_to_hi())) } } else { None }; <del> let err = errors::UnknownPrefix { span: prefix_span, prefix, sugg }; if silence { self.dcx().create_err(err).delay_as_bug(); } else { self.dcx().emit_err(err); } </del> <ins> self.dcx().emit_err(errors::UnknownPrefix { span: prefix_span, prefix, sugg }); </ins> } else { // Before Rust 2021, only emit a lint for migration. self.psess.buffer_lint_with_diagnostic(


Question:
<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced

<ins> //@ edition:2021 macro_rules! a { ( ) => { impl<'b> c for d { e::<f'g> //~ ERROR prefix `f` is unknown } }; } fn main() {} </ins>


Question:
<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced

<ins> error: prefix `f` is unknown --> $DIR/dont-ice-on-invalid-lifetime-in-macro-definition.rs:5:17 | LL |             e::<f'g> |                 ^ unknown prefix | = note: prefixed identifiers and literals are reserved since Rust 2021 help: consider inserting whitespace here | LL |             e::<f 'g> |                  + error: aborting due to 1 previous error </ins>


Question:
<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced

//@[rust2021] edition:2021 fn main() { println!('hello world'); <del> //[rust2015,rust2018,rust2021]~^ ERROR unterminated character literal </del> <ins> //~^ ERROR unterminated character literal //[rust2021]~| ERROR prefix `world` is unknown </ins> }


Question:
<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced

<ins> error: prefix `world` is unknown --> $DIR/lex-bad-str-literal-as-char-3.rs:5:21 | LL |     println!('hello world'); |                     ^^^^^ unknown prefix | = note: prefixed identifiers and literals are reserved since Rust 2021 help: if you meant to write a string literal, use double quotes | LL |     println!("hello world"); |              ~           ~ </ins> error[E0762]: unterminated character literal --> $DIR/lex-bad-str-literal-as-char-3.rs:5:26 |


Question:
<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced

LL |     println!("hello world"); |              ~           ~ <del> error: aborting due to 1 previous error </del> <ins> error: aborting due to 2 previous errors </ins> For more information about this error, try `rustc --explain E0762`.


Question:
<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced

<ins> //@edition:2021 macro_rules! foo { () => { println!('hello world'); //~^ ERROR unterminated character literal //~| ERROR prefix `world` is unknown } } fn main() {} </ins>


Question:
<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced

<ins> error: prefix `world` is unknown --> $DIR/lex-bad-str-literal-as-char-4.rs:4:25 | LL |         println!('hello world'); |                         ^^^^^ unknown prefix | = note: prefixed identifiers and literals are reserved since Rust 2021 help: if you meant to write a string literal, use double quotes | LL |         println!("hello world"); |                  ~           ~ error[E0762]: unterminated character literal --> $DIR/lex-bad-str-literal-as-char-4.rs:4:30 | LL |         println!('hello world'); |                              ^^^ | help: if you meant to write a string literal, use double quotes | LL |         println!("hello world"); |                  ~           ~ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0762`. </ins>


Question:
In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test:

ast::Path { span, segments, tokens: None } } <ins> pub fn macro_call( &self, span: Span, path: ast::Path, delim: ast::token::Delimiter, tokens: ast::tokenstream::TokenStream, ) -> P<ast::MacCall> { P(ast::MacCall { path, args: P(ast::DelimArgs { dspan: ast::tokenstream::DelimSpan { open: span, close: span }, delim, tokens, }), }) } </ins> pub fn ty_mt(&self, ty: P<ast::Ty>, mutbl: ast::Mutability) -> ast::MutTy { ast::MutTy { ty, mutbl } }


Question:
In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test:

self.expr(span, ast::ExprKind::Field(expr, field)) } <ins> pub fn expr_macro_call(&self, span: Span, call: P<ast::MacCall>) -> P<ast::Expr> { self.expr(span, ast::ExprKind::MacCall(call)) } </ins> pub fn expr_binary( &self, sp: Span,


Question:
In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test:

self.expr(sp, ast::ExprKind::Tup(exprs)) } <del> pub fn expr_fail(&self, span: Span, msg: Symbol) -> P<ast::Expr> { self.expr_call_global( </del> <ins> pub fn expr_unreachable(&self, span: Span) -> P<ast::Expr> { self.expr_macro_call( </ins> span, <del> [sym::std, sym::rt, sym::begin_panic].iter().map(|s| Ident::new(*s, span)).collect(), thin_vec![self.expr_str(span, msg)], </del> <ins> self.macro_call( span, self.path_global( span, [sym::std, sym::unreachable].map(|s| Ident::new(s, span)).to_vec(), ), ast::token::Delimiter::Parenthesis, ast::tokenstream::TokenStream::default(), ), </ins> ) } <del> pub fn expr_unreachable(&self, span: Span) -> P<ast::Expr> { self.expr_fail(span, Symbol::intern("internal error: entered unreachable code")) } </del> pub fn expr_ok(&self, sp: Span, expr: P<ast::Expr>) -> P<ast::Expr> { let ok = self.std_path(&[sym::result, sym::Result, sym::Ok]); self.expr_call_global(sp, ok, thin_vec![expr])


Question:
In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test:

<ins> #![crate_type = "lib"] pub trait Decoder { type Error; fn read_enum<T, F>(&mut self, name: &str, f: F) -> Result<T, Self::Error> where F: FnOnce(&mut Self) -> Result<T, Self::Error>; fn read_enum_variant<T, F>(&mut self, names: &[&str], f: F) -> Result<T, Self::Error> where F: FnMut(&mut Self, usize) -> Result<T, Self::Error>; } pub trait Decodable: Sized { fn decode<D: Decoder>(d: &mut D) -> Result<Self, D::Error>; } </ins>


Question:
In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test:

<ins> //@ check-pass //@ edition:2021 //@ aux-build:rustc-serialize.rs #![crate_type = "lib"] #![allow(deprecated, soft_unstable)] extern crate rustc_serialize; #[derive(RustcDecodable)] pub enum Foo {} </ins>


Question:
In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test:

<ins> Future incompatibility report: Future breakage diagnostic: warning: use of unstable library feature 'rustc_encodable_decodable': derive macro for `rustc-serialize`; should not be used in new code --> $DIR/rustc-decodable-issue-123156.rs:10:10 | LL | #[derive(RustcDecodable)] |          ^^^^^^^^^^^^^^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #64266 <https://github.com/rust-lang/rust/issues/64266> </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: I expected to see this happen: There should be a remainder as will not be yielded. Instead, this happened: If this is intended behavior, then it should probably be documented, as the current documentation of states that it: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

/// Returns an iterator over the remaining elements of the original iterator /// that are not going to be returned by this iterator. The returned /// iterator will yield at most `N-1` elements. <ins> /// /// # Example /// ``` /// # // Also serves as a regression test for https://github.com/rust-lang/rust/issues/123333 /// # #![feature(iter_array_chunks)] /// let x = [1,2,3,4,5].into_iter().array_chunks::<2>(); /// let mut rem = x.into_remainder().unwrap(); /// assert_eq!(rem.next(), Some(5)); /// assert_eq!(rem.next(), None); /// ``` </ins> #[unstable(feature = "iter_array_chunks", reason = "recently added", issue = "100450")] #[inline] <del> pub fn into_remainder(self) -> Option<array::IntoIter<I::Item, N>> { </del> <ins> pub fn into_remainder(mut self) -> Option<array::IntoIter<I::Item, N>> { if self.remainder.is_none() { while let Some(_) = self.next() {} } </ins> self.remainder } }


Question:
While checkout out this ice (which does not require a feature gate btw, so potential beta-to-stable regression, which is inconvenient <!-- ICE: Rustc '' 'error: internal compiler error: unsupported pattern for pattern type: Pat {', 'error: internal compiler error: unsupported pattern for pattern type: Pat {' 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: [typeof] expanding type alias [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --I clicked the tracking issue from = note: see issue more information = help: add to the crate attributes to enable = note: this compiler was built on 2024-04-08; consider upgrading it if it is out of date which is about an attribute and does not mention patterns or links to a related PR at all? :thinking:
What do you mean? Why would this beta a beta-to-stable regression? It regressed with .
cc pattern types need a real tracking issue, and you need to delay a span bug here rather than ICE
right now: beta -nightly regression once nightly gets promoted to beta: stable -beta regression once beta gets promoted to stable: stable -stable regression?
yes? but you can say that about every single regression that ever gets filed lol
exactly, unless it gets fixed in time :)
I don't see the purpose of pointing out that this is a potential beta regression before it has even landed on nightly, unless there's some reason that this is particularly difficult to fix, particularly affects user-facing code, or we expect it to slip the beta promotion for some reason.
Well, there are a few cases where feature gates actually do work and prevent crashes on stable
maybe internal features should just hard abort compilation if they aren't set
might also solve some of the internal-feature ices we are getting from time to time
...I do not see how it would be a regression, because we can safely bet on no one requiring the macro before the feature's library API landed. The code did not travel back in time to 1.77 compilers and suddenly become usable stable API.
its a regression because the compiler now crashes/ICEs where it would previously just show an error message.
please show me the codebase that regressed.
code that was not committed until April 8th, thus incapable of regressing on stable, yes.
ah yes not yet. this is why I wrote ;)
If it arrived on 1.79 on stable, it would be code that, since the moment it has been useful to write, has always ICEd. 1.79 cannot retrocausally regress code, unless you have a TARDIS or somesuch.
I it was code that did not ICE on 1.78, and now ICEs on 1.79, so that makes it a regression.
It was code that did not exist in this world on 1.78. It didn't exist in some timeless platonic realm of Forms. No actual programs were harmed in the making of this music video.
I suppose if you insist we can call them "regressions" when they involve code samples that just came into being, but I wish to know what I should call it when my actual tests fail from version to version of rustc and I have to spend hours bisecting the issue and figuring out where in the codebase it has gone wrong and fixing the problem before the new version comes out, either in the code or in rustc. Because it sure isn't a just-fabricated problem with just-fabricated code, it's something that matters in code that is supposed to build and work on the latest stable Rust version.
What it is is a feature gated feature ICEing without the feature gate, so we would see it ICE on stable if untreated. This means it is a higher priority ICE than an ICE that is only reachable with feature gates. We have not used "regression" as a term for "error -ICE" changes, as by definition that'a true for any ICE that does not require feature gates. If we flagged it as a regression, that would flood and taint the actually problematic regressions. We do flag these as regressions if there is no error before the ICE, as the user then has no information on how to fix it. So while is technically correct, in practice we don't and shouldn't use this terminology

/// Set the maximum pattern complexity allowed (not limited by default). (internal, pattern_complexity, "1.78.0", None), /// Allows using pattern types. <del> (internal, pattern_types, "CURRENT_RUSTC_VERSION", Some(54882)), </del> <ins> (internal, pattern_types, "CURRENT_RUSTC_VERSION", Some(123646)), </ins> /// Allows using `#[prelude_import]` on glob `use` items. (internal, prelude_import, "1.2.0", None), /// Used to identify crates that contain the profiler runtime.


Question:
While checkout out this ice (which does not require a feature gate btw, so potential beta-to-stable regression, which is inconvenient <!-- ICE: Rustc '' 'error: internal compiler error: unsupported pattern for pattern type: Pat {', 'error: internal compiler error: unsupported pattern for pattern type: Pat {' 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: [typeof] expanding type alias [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --I clicked the tracking issue from = note: see issue more information = help: add to the crate attributes to enable = note: this compiler was built on 2024-04-08; consider upgrading it if it is out of date which is about an attribute and does not mention patterns or links to a related PR at all? :thinking:
What do you mean? Why would this beta a beta-to-stable regression? It regressed with .
cc pattern types need a real tracking issue, and you need to delay a span bug here rather than ICE
right now: beta -nightly regression once nightly gets promoted to beta: stable -beta regression once beta gets promoted to stable: stable -stable regression?
yes? but you can say that about every single regression that ever gets filed lol
exactly, unless it gets fixed in time :)
I don't see the purpose of pointing out that this is a potential beta regression before it has even landed on nightly, unless there's some reason that this is particularly difficult to fix, particularly affects user-facing code, or we expect it to slip the beta promotion for some reason.
Well, there are a few cases where feature gates actually do work and prevent crashes on stable
maybe internal features should just hard abort compilation if they aren't set
might also solve some of the internal-feature ices we are getting from time to time
...I do not see how it would be a regression, because we can safely bet on no one requiring the macro before the feature's library API landed. The code did not travel back in time to 1.77 compilers and suddenly become usable stable API.
its a regression because the compiler now crashes/ICEs where it would previously just show an error message.
please show me the codebase that regressed.
code that was not committed until April 8th, thus incapable of regressing on stable, yes.
ah yes not yet. this is why I wrote ;)
If it arrived on 1.79 on stable, it would be code that, since the moment it has been useful to write, has always ICEd. 1.79 cannot retrocausally regress code, unless you have a TARDIS or somesuch.
I it was code that did not ICE on 1.78, and now ICEs on 1.79, so that makes it a regression.
It was code that did not exist in this world on 1.78. It didn't exist in some timeless platonic realm of Forms. No actual programs were harmed in the making of this music video.
I suppose if you insist we can call them "regressions" when they involve code samples that just came into being, but I wish to know what I should call it when my actual tests fail from version to version of rustc and I have to spend hours bisecting the issue and figuring out where in the codebase it has gone wrong and fixing the problem before the new version comes out, either in the code or in rustc. Because it sure isn't a just-fabricated problem with just-fabricated code, it's something that matters in code that is supposed to build and work on the latest stable Rust version.
What it is is a feature gated feature ICEing without the feature gate, so we would see it ICE on stable if untreated. This means it is a higher priority ICE than an ICE that is only reachable with feature gates. We have not used "regression" as a term for "error -ICE" changes, as by definition that'a true for any ICE that does not require feature gates. If we flagged it as a regression, that would flood and taint the actually problematic regressions. We do flag these as regressions if there is no error before the ICE, as the user then has no information on how to fix it. So while is technically correct, in practice we don't and shouldn't use this terminology

Ty::new_pat(tcx, ty, pat) } hir::PatKind::Err(e) => Ty::new_error(tcx, e), <del> _ => span_bug!(pat.span, "unsupported pattern for pattern type: {pat:#?}"), </del> <ins> _ => Ty::new_error_with_message( tcx, pat.span, format!("unsupported pattern for pattern type: {pat:#?}"), ), </ins> }; self.record_ty(pat.hir_id, ty, pat.span); pat_ty