ICE: "cannot convert ReErased to a region vid" for let const { "foo" } = "foo"
#78174
Comments
camelid
added
I-ICE
|
The ICE occurs with let "foo" = const { "foo" };and let const { "foo" } = const { "foo" };as well. |
|
Cc @spastorino – this issue is from the implementation of #77124 |
|
This may be relevant (introduced in that PR): rust/compiler/rustc_mir_build/src/thir/pattern/mod.rs Lines 859 to 863 in 03321b8 |
This fails with the correct error#![allow(incomplete_features)]
#![feature(inline_const)]
fn main() {
let const { 1 } = &1;
}Errors: This ICEs#![allow(incomplete_features)]
#![feature(inline_const)]
fn main() {
let const { &1 } = &1;
}Errors: Diff fn main() {
- let const { 1 } = &1;
let const { &1 } = &1;
} |
camelid
changed the title
let const { "foo" } = "foo"ReErased to a region vid" for let const { "foo" } = "foo"
|
A possible duplicate. struct ArpIPv4<'a> {}
impl<'a> ArpIPv4<'a> {
const LENGTH: usize;
fn to_buffer() -> [u8; Self::LENGTH] {}
} |
|
Another possible duplicate: #![feature(inline_const)]
fn main() {
match "foo" {
const {"foo"} => println!("It works!"),
_ => (),
}
} |
|
This throws ICEs on stable. Pretty sure you're not supposed to get ICEs on stable, even if they relate to nightly features? fn main() {
let const { "foo" } = "foo";
} |
|
I think that's expected since the compiler usually continues compiling even if you use a nightly feature on stable (it emits an error, but keeps going since there's not anything wrong with your code per se). |
|
I turned up this variant on this ICE last night! Playground #![feature(inline_const)]
fn main() {
let value: &[u8] = b"Any";
match value {
const { stringify!(Any).as_bytes() } => println!("Yo!"),
_ => println!("Boo!")
}
}Not really different, just thought it was mildly interesting due to the
```bash
RUST_BACKTRACE=full rustc rustc_test.rs --verbose
warning: the feature `inline_const` is incomplete and may not be safe to use and/or cause compiler crashes
--> rustc_test.rs:1:12
|
1 | #![feature(inline_const)]
| ^^^^^^^^^^^^
|
= note: `#[warn(incomplete_features)]` on by default
= note: see issue #76001 for more information
error: internal compiler error: compiler/rustc_mir/src/borrow_check/universal_regions.rs:768:36: cannot convert thread 'rustc' panicked at 'Box', compiler/rustc_errors/src/lib.rs:958:9 note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug, I-ICE, T-compiler&template=ice.md note: rustc 1.51.0-nightly (a2f8f62 2021-01-27) running on x86_64-unknown-linux-gnu query stack during panic: |
Use AnonConst for asm! constants This replaces the old system which used explicit promotion. See rust-lang#83169 for more background. The syntax for `const` operands is still the same as before: `const <expr>`. Fixes rust-lang#83169 Because the implementation is heavily based on inline consts, we suffer from the same issues: - We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`. - We are hitting the same ICEs as inline consts, for example rust-lang#78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
Use AnonConst for asm! constants This replaces the old system which used explicit promotion. See rust-lang#83169 for more background. The syntax for `const` operands is still the same as before: `const <expr>`. Fixes rust-lang#83169 Because the implementation is heavily based on inline consts, we suffer from the same issues: - We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`. - We are hitting the same ICEs as inline consts, for example rust-lang#78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
Use AnonConst for asm! constants This replaces the old system which used explicit promotion. See rust-lang#83169 for more background. The syntax for `const` operands is still the same as before: `const <expr>`. Fixes rust-lang#83169 Because the implementation is heavily based on inline consts, we suffer from the same issues: - We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`. - We are hitting the same ICEs as inline consts, for example rust-lang#78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
|
Also got bitten (the same error, not sure if the exact same cause): #![feature(inline_const)]
fn main() {
let vals = const { &[1] };
} |
|
Many of the ICEs here seem to be caused by using But some examples don't involve any patterns. The backtrace for @Patryk27's example is Sadly the borrowck code is way outside my expertise in rustc. @oli-obk any idea who'd be a good candidate for looking at these problems? |
|
I don't know anyone with free capacities to look at this. From a cursory glance I would say it is promotion related. If someone wants to dig into this, dumping the MIR before mir borrowck and checking the exact lifetimes that show up is probably the right way. Maybe it is incorrect for us to use |
|
@rustbot claim |
Type inference for inline consts Fixes rust-lang#78132 Fixes rust-lang#78174 Fixes rust-lang#81857 Fixes rust-lang#89964 Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `@spastorino` `@lcnr` r? `@nikomatsakis` `@rustbot` label A-inference F-inline_const T-compiler
Type inference for inline consts Fixes rust-lang#78132 Fixes rust-lang#78174 Fixes rust-lang#81857 Fixes rust-lang#89964 Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc ``@spastorino`` ``@lcnr`` r? ``@nikomatsakis`` ``@rustbot`` label A-inference F-inline_const T-compiler
Type inference for inline consts Fixes rust-lang#78132 Fixes rust-lang#78174 Fixes rust-lang#81857 Fixes rust-lang#89964 Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc ```@spastorino``` ```@lcnr``` r? ```@nikomatsakis``` ```@rustbot``` label A-inference F-inline_const T-compiler
Type inference for inline consts Fixes rust-lang#78132 Fixes rust-lang#78174 Fixes rust-lang#81857 Fixes rust-lang#89964 Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc ````@spastorino```` ````@lcnr```` r? ````@nikomatsakis```` ````@rustbot```` label A-inference F-inline_const T-compiler
Type inference for inline consts Fixes rust-lang#78132 Fixes rust-lang#78174 Fixes rust-lang#81857 Fixes rust-lang#89964 Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler
Code
About as minimal of an example as it gets :)
playground
Meta
Version
On the playground, so I don't think I can access the rest, but:
rustc 1.49.0-nightly (b1496c6e6 2020-10-18) running on x86_64-unknown-linux-gnuThis is a nightly-only feature, so I can't test on stable or beta :)
Error output
Backtrace
The text was updated successfully, but these errors were encountered: