-
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: assertion failed: layout.is_sized()
#124182
Comments
searched nightlies: from nightly-2024-01-01 to nightly-2024-04-19 bisected with cargo-bisect-rustc v0.6.8Host triple: aarch64-apple-darwin cargo bisect-rustc --start=2024-01-01 --end=2024-04-19 --preserve --regress=ice It points to #121087 |
Smaller: playground struct LazyLock {
data: ([u8], ()),
}
static EMPTY_SET: LazyLock = todo!();
fn main() {} |
Preexisting on stable: struct LazyLock {
data: ([u8], ()),
}
const EMPTY_SET: LazyLock = todo!();
const _: [(); {
EMPTY_SET;
0
}] = [];
fn main() {} |
Trying to solve this issue, here is what I got. The problem is that the trait solver only checks the last element of tuple when processing Perhaps we can make |
That can't be done, as wfcheck runs various consteval things that quickly result in (undesirable) cycle errors
We just had issues like that a few months ago. Please check which PRs tried to fix that. We may just want to revert them and correctly do |
#122078 added a To fix this issue, |
layout computation: gracefully handle unsized types in unexpected locations This PR reworks the layout computation to eagerly return an error when encountering an unsized field where a sized field was expected, rather than delaying a bug and attempting to recover a layout. This is required, because with trivially false where clauses like `[T]: Sized`, any field can possible be an unsized type, without causing a compile error. Since this PR removes the `delayed_bug` method from the `LayoutCalculator` trait, it essentially becomes the same as the `HasDataLayout` trait, so I've also refactored the `LayoutCalculator` to be a simple wrapper struct around a type that implements `HasDataLayout`. The majority of the diff is whitespace changes, so viewing with whitespace ignored is advised. implements rust-lang/rust#123169 (comment) r? `@compiler-errors` or compiler fixes rust-lang/rust#123134 fixes rust-lang/rust#124182 fixes rust-lang/rust#126939 fixes rust-lang/rust#127737
layout computation: gracefully handle unsized types in unexpected locations This PR reworks the layout computation to eagerly return an error when encountering an unsized field where a sized field was expected, rather than delaying a bug and attempting to recover a layout. This is required, because with trivially false where clauses like `[T]: Sized`, any field can possible be an unsized type, without causing a compile error. Since this PR removes the `delayed_bug` method from the `LayoutCalculator` trait, it essentially becomes the same as the `HasDataLayout` trait, so I've also refactored the `LayoutCalculator` to be a simple wrapper struct around a type that implements `HasDataLayout`. The majority of the diff is whitespace changes, so viewing with whitespace ignored is advised. implements rust-lang/rust#123169 (comment) r? `@compiler-errors` or compiler fixes rust-lang/rust#123134 fixes rust-lang/rust#124182 fixes rust-lang/rust#126939 fixes rust-lang/rust#127737
Code
I couldn't simplify the code without making it harder to understand.
Meta
rustc --version --verbose
:Command
rustc
Error output
Backtrace
Note
ICE-loc:
compiler/rustc_const_eval/src/const_eval/eval_queries.rs:54:5
rust/compiler/rustc_const_eval/src/const_eval/eval_queries.rs
Lines 53 to 54 in e3181b0
assertion failed: layout.is_sized()
#121443. But at first glance I cannot understand why they triggers same ICE location.Original ICE-triggering code is mutated from test-file
trait-method-ptr-in-consts-ice.rs
rust/tests/ui/rfcs/rfc-2632-const-trait-impl/trait-method-ptr-in-consts-ice.rs
Lines 3 to 5 in f9b1614
The text was updated successfully, but these errors were encountered: