-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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: !layout.abi.is_uninhabited()
#120337
Comments
|
I agree. Nobody should be testing But this is a bug. I've found this in real code with a much smaller set of flags:
And this bisects to #119627 Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain. |
Afaict @matthiaskrgr likes to do ICE testing against master 😺 |
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it. |
Another one with pub enum HiddenType {}
pub trait HiddenTrait {}
pub enum MyLibType {}
impl From<HiddenType> for MyLibType {
fn from(it: HiddenType) -> MyLibType {
match it {}
}
}
pub struct T<T>(T);
impl From<T<T<T<T<HiddenType>>>>> for MyLibType {
fn from(it: T<T<T<T<HiddenType>>>>) -> MyLibType {
todo!()
}
} |
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
|
Looks like there is one more issue in GVN ( #![feature(never_type)]
#[derive(Copy, Clone)]
pub enum E { A(!, u32), }
pub union U { i: u32, e: E, }
pub const fn f() -> u32 {
let E::A(_, i) = unsafe { (&U { i: 0 }).e } ;
i
} |
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant: #![feature(never_type)]
#[derive(Copy, Clone)]
pub enum E { A(!), }
pub union U { u: (), e: E, }
pub const C: () = {
let E::A(ref a) = unsafe { &(&U { u: () }).e};
}; |
@tmiasko nice example! |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-medium |
interpret: project_downcast: do not ICE for uninhabited variants Fixes rust-lang/rust#120337 This assertion was already under discussion for a bit; I think the [example](rust-lang/rust#120337 (comment)) `@tmiasko` found is the final nail in the coffin. One could argue maybe MIR building should read the discriminant before projecting, but even then MIR optimizations should be allowed to remove that read, so the downcast should still not ICE. Maybe the downcast should be UB, but in this example UB already arises earlier when a value of type `E` is constructed. r? `@oli-obk`
Code
Meta
rustc --version --verbose
:Error output
rustc --edition=2021 -Zvalidate-mir -Zmir-opt-level=5 -Zunsound-mir-opts treereduce.out
Backtrace
The text was updated successfully, but these errors were encountered: