const-eval can construct uninhabited values or other unconstructable values out-of-thin-air via recursive static initialization

View all comments

Based on an example by @theemathas:

enum Never {}

static X: &Never = weird(&X);

const fn weird(a: &&Never) -> &'static Never {
    // SAFETY: our argument type has an unsatisfiable
    // library invariant; therefore, this code is unreachable.
    unsafe { std::hint::unreachable_unchecked() };
}

error[E0080]: could not evaluate static initializer
   --> src/lib.rs:3:20
    |
3   | static X: &Never = weird(&X);
    |                    ^^^^^^^^^ entering unreachable code
    |
note: inside `weird`
   --> src/lib.rs:8:14
    |
8   |     unsafe { std::hint::unreachable_unchecked() };
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside `unreachable_unchecked`
   --> /playground/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/hint.rs:109:14
    |
109 |     unsafe { intrinsics::unreachable() }
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^ the failure occurred here

I can't see anything wrong about weird. Therefore, this is UB from entirely sound code.

Here's another example that defers the UB to runtime.

See below for an example that involves a library invariant instead of an uninhabited type.

Cc @rust-lang/opsem @rust-lang/wg-const-eval

Start by running the recursive static-initialization reproducer shown in src/lib.rs and compare it with the linked runtime example. Read the const-eval and opsem context, including the referenced core/src/hint.rs implementation, then establish the soundness impact and the precise behavior that must be corrected or documented.