-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICE: Failed to get layout for [type error]
:
#70507
Comments
[type error]
:[type error]
:
When I switch from “Run” to “Build” in the playground, the error changes. Long error message (collapsed)
When I change the call slice.const_chunks_exact::<{3usize}>() into <[i32] as ConstChunksExactTrait<i32>>::const_chunks_exact::<{3usize}>(slice) the ICE disappears. (The code segfaults though.) Bisection gives: |
On that segfault, thats my own mistake, the Iterator should yield items of type |
Yeah, that’s what I thought, the segfault being a bug in the Here’s a smaller example: #![feature(const_generics)]
struct R;
impl R {
fn method<const N: u8>(&self) {}
}
fn main() {
R.method::<1u8>();
} Errors:
Edit: This smaller example seems to behave slightly different in that it does produce a (however different) ICE even before nightly-2020-03-25. In the original example when compiling as a library (i.e. “Build” vs “Run”), that other ICE appears before that regression, too. In other words, the bisection above only applies to the error in this issue’s title – the one that OP got. Edit2: The error before nightly-2020-03-25 looks a lot like #68596. For the record: error before nightly-2020-03-25
|
Minimal repro (playground): #![feature(const_generics)]
struct Foo;
impl Foo {
fn foo<const N: usize>(self) {}
}
fn main() {
Foo.foo();
} The problem is a method call with uninferred rust/src/librustc_typeck/check/writeback.rs Lines 673 to 674 in b2c1a60
|
When the function doesn't reach codegen, we get #![feature(const_generics)]
struct Foo;
impl Foo {
fn foo<const N: usize>(self) {}
}
fn test() {
Foo.foo();
}
It's important to note that this is the same thing. The ICEs are just a symptom of a |
This in turn depends on rust/src/librustc_infer/infer/error_reporting/need_type_info.rs Lines 226 to 233 in 8d67f57
need_type_info_err currently has a lot of special handling for different situations, but maybe we can add in a simple path for consts?
|
correctly handle uninferred consts fixes the ICE mentioned in rust-lang#70507 (comment) I originally tried to generalize `need_type_info_err` to also work with consts which was not as much fun as I hoped 😅 It might be easier to have some duplication here and handle consts separately. r? @varkor
correctly handle uninferred consts fixes the ICE mentioned in rust-lang#70507 (comment) I originally tried to generalize `need_type_info_err` to also work with consts which was not as much fun as I hoped 😅 It might be easier to have some duplication here and handle consts separately. r? @varkor
const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes rust-lang#61936 closes rust-lang#62878 closes rust-lang#63695 closes rust-lang#67144 closes rust-lang#68596 closes rust-lang#69816 closes rust-lang#70217 closes rust-lang#70507 closes rust-lang#70586 closes rust-lang#71348 closes rust-lang#71805 closes rust-lang#73120 closes rust-lang#73508 closes rust-lang#73730 closes rust-lang#74255
I hit this ice when trying implement #60735.
The ice message looks very similar to #70291, which has been closed already.
Code
Meta
rustc --version --verbose
:Backtrace
The text was updated successfully, but these errors were encountered: