-
Notifications
You must be signed in to change notification settings - Fork 13.4k
ICE: Failed to get layout for [type error]
:
#70507
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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
Uh oh!
There was an error while loading. Please reload this page.
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: