-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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]
: the type [type error]
has an unknown layout
#102366
Comments
This might not fix the underlying issue but I'll at least make the ICE look less cursed |
Btw, I can reproduce this on the latest nightly
|
With #102373 I now get this backtrace: Backtrace
The error was originally emitted in rust/compiler/rustc_hir_analysis/src/check/expr.rs Lines 518 to 527 in 57ee5cf
|
I guess "less cursed" is subjective then 😄 Anyway, the PR seems a good step forward: I didn't know there was a bug in the bug that made it difficult to track down the actual bug. 👍 |
I have actually experienced the same ICE yesterday in my own code when I was working on AST lowering and lowered things in the wrong order. It seems like this kind of late path resolution failure happens when path resolution initially succeeds, but then something (like a broken AST lowering) happens which causes the path to suddenly stop resolving in typeck. Typeck then doesn't know any better than to create a type error type (which causes the mass of delayed ICEs) and continue, which doesmakes sense, as this path is hit as well when the code has a real path resolution error that is correctly detected and emitted earlier. |
…nch-error, r=cjgillot Flush delayed bugs before codegen Sometimes it can happen that invalid code like a TyKind::Error makes its way through the compiler without triggering any errors (this is always a bug in rustc but bugs do happen sometimes :)). These ICEs will manifest in the backend like as cg_llvm not being able to get the layout of `[type error]`, which makes it hard to debug. By flushing before codegen, we display all the delayed bugs, making it easier to trace it to the root of the problem. I tried this on rust-lang#102366 and it showed tons of of delayed bugs and no error in cg_llvm, so it seems to be working.
Hello! This is a strange bug that I'm reporting. I don't have the slightest idea of what it does, nor is it very relevant how I encountered this bug. I report it because it might unveil something important. Anyway, here it is.
Code
Make a new lib with
cargo new --lib rustc-bug
and put this insrc/lib.rs
:That's it: an empty module with a single documentation comment with a doc-test.
Now, if you are ready for the bang, run
cargo test --doc
and you'll be welcomed withThe full backtrace is at the end.
Meta
rustc --version --verbose
:The same bug persists if I run it with this nightly version:
Error output
Backtrace
The text was updated successfully, but these errors were encountered: