`match` on uninhabited type does not trigger UB in Miri

[theemathas]

I tried this code:

#![allow(deref_nullptr)]

enum Never {}

fn main() {
    unsafe {
        match *std::ptr::null::<Result<Never, Never>>() {
            Ok(_) => {
                lol();
            }
            Err(_) => {
                wut();
            }
        }
    }
}

fn lol() {
    println!("lol");
}

fn wut() {
    println!("wut");
}

I expected to see this happen: Running this with Miri detects undefined behavior.

Instead, this happened: Running this with Miri outputs "lol", and program exits successfully.

It seems like rustc is discarding the second match arm entirely in the MIR?

MIR

// WARNING: This output format is intended for human consumers only
// and is subject to change without notice. Knock yourself out.
// HINT: See also -Z dump-mir for MIR at specific points during compilation.
fn main() -> () {
    let mut _0: ();
    let mut _1: *const std::result::Result<Never, Never>;
    let _2: ();

    bb0: {
        _1 = null::<Result<Never, Never>>() -> [return: bb1, unwind continue];
    }

    bb1: {
        _2 = lol() -> [return: bb2, unwind continue];
    }

    bb2: {
        return;
    }
}

// MIR for lol() and wut() omitted for brevity

Meta

Reproducible on the playground with 1.89.0-nightly (2025-06-10 1677d46cb128cc8f285d)

@rustbot labels +A-patterns

[xizheyin]

This may because, if either type parameter of Result is Never, the Rust compiler treats the type as uninhabitable and optimizes away the code, so dereferencing a null pointer doesn't cause a crash; but with Result<i32, i32>, the type is inhabited, so dereferencing null will lead to a segmentation fault.

[theemathas]

Miri is supposed to run on unoptimized code.

[saethlin]

This may because, if either type parameter of Result is Never, the Rust compiler treats the type as uninhabitable and optimizes away the code, so dereferencing a null pointer doesn't cause a crash; but with Result<i32, i32>, the type is inhabited, so dereferencing null will lead to a segmentation fault.

No. The fact that the pointer here is null is an unnecessary distraction that I didn't realize last night. Result<Never, Never> is a ZST, and our documentation clearly states:

For memory accesses of size zero, every pointer is valid, including the null pointer.

Moreover, if you look at the MIR you can see that we never even emit a read. The dereference is fine.

This code has the same strange lowering:

enum Never {}

fn main(p: *const Result<Never, Never>) {
    unsafe {
        match *p {
            Ok(_) => {
                lol();
            }
            Err(_) => {
                wut();
            }
        }
    }
}

fn lol() {
    println!("lol");
}

fn wut() {
    println!("wut");
}

[kpreid]

This seems closely related to rust-lang/unsafe-code-guidelines#540, and arguably corresponds to a gap in the definition of what is UB — what are the steps executing a pattern match actually performs? Which one of those steps is is UB when an uninhabited value is matched — not ever produced, yet matched?

Here is a simpler program that also passes Miri:

enum Never {} // also works with ! type

fn main() {
    unsafe {
        match *std::ptr::dangling::<Never>() {
            _ => println!("never happened"),
        }
    }
}

This one lacks the puzzle of “which of the match arms should be run? neither, of course”, though, and one could perhaps argue that it shouldn’t be UB since there is no branch and Rust prefers not to have entirely gratuitous UB. Yet, what semantics justifies that?

[kpreid]

Here are a couple of possible high-level statements of where the UB should be (these do not reflect the current documented semantics of Rust, but could in the future):

1. The discriminant of Result<Never, Never> is, itself, uninhabited. Therefore, reading it to match it is “producing an invalid value” UB for std::mem::Discriminant<Result<Never, Never>> or an equivalent internal construct.
2. A match arm whose pattern is uninhabited should be unreachable; its body should never execute. Therefore, none of the arms of these matches match, and control flow falls off the end of the match, which should be defined as UB.

[RalfJung]

I agree this should be UB -- I'd have expected a discriminant read that causes UB here. But somehow we don't get one?
Cc @Nadrieril

[RalfJung]

The MIR is already odd immediately after being built:

fn main(_1: *const Result<Never, Never>) -> () {
    debug p => _1;
    let mut _0: ();
    let _2: ();
    let _3: ();

    bb0: {
        PlaceMention((*_1));
        falseEdge -> [real: bb3, imaginary: bb1];
    }

    bb1: {
        StorageLive(_3);
        _3 = wut() -> [return: bb5, unwind: bb7];
    }

    bb2: {
        FakeRead(ForMatchedPlace(None), (*_1));
        unreachable;
    }

    bb3: {
        StorageLive(_2);
        _2 = lol() -> [return: bb4, unwind: bb7];
    }

Note the entire lack of a discriminant check.