Uninhabited types result in strange criteria of irrefutable patterns.

I'm not sure if this is a bug or not.

The following code compiles without errors:

enum Never {}

fn foo(x: (i32, Never)) {
    let (123, _) = x;
}

The compiler seems to consider the (123, _) to be an irrefutable pattern. This is rather strange. But it doesn't really cause any harm, since constructing an (i32, Never) value is UB anyway.

However, things get more interesting when #![feature(exhaustive_patterns)] is involved. See the following code:

#![feature(exhaustive_patterns)]

use std::mem::MaybeUninit;

enum Never {}

fn foo(x: *mut (i32, Never)) {
    unsafe {
        let (123, _) = *x;
    }
}

fn main() {
    let mut data: MaybeUninit<(i32, Never)> = MaybeUninit::uninit();
    let ptr: *mut (i32, Never) = data.as_mut_ptr();
    unsafe { (&raw mut (*ptr).0).write(123); }
    foo(ptr); // This is OK
    println!("called with 123 without UB");
    unsafe { (&raw mut (*ptr).0).write(456); }
    foo(ptr); // This is UB
}

When ran in Miri, the code outputs called with 123 without UB, and then reports the following UB:

error: Undefined Behavior: entering unreachable code
 --> src/main.rs:9:13
  |
9 |         let (123, _) = *x;
  |             ^^^^^^^^ Undefined Behavior occurred here
  |
  = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
  = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
  = note: stack backtrace:
          0: foo
              at src/main.rs:9:13: 9:21
          1: main
              at src/main.rs:20:5: 20:13

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

That is, the line let (123, _) = *x; checks whether (*x).0 is 123 or not. If it's not, then UB happens.

This can be confirmed by inspecting the MIR for foo:

fn foo(_1: *mut (i32, Never)) -> () {
    debug x => _1;
    let mut _0: ();
    scope 1 {
    }

    bb0: {
        switchInt(copy ((*_1).0: i32)) -> [123: bb2, otherwise: bb1];
    }

    bb1: {
        unreachable;
    }

    bb2: {
        return;
    }
}

Is a let statement supposed to be able to conditionally cause UB like this?

cc @Nadrieril @RalfJung

Meta

Reproducible on the playground with version 1.98.0-nightly (2026-06-17 c1b22f44c3f30e186b82)

Reproduce the examples on the stated nightly version, run the Miri case, and inspect the MIR generated for foo. Start by determining how let patterns involving uninhabited types and exhaustive_patterns are intended to behave; done means the language semantics and compiler behavior agree, with regression coverage for the demonstrated case.