Uninhabited types have strange borrow-checking behavior, even behind references

[theemathas]

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

enum Never {}

fn works(x: &mut Result<Never, String>) {
    match x {
        &mut Ok(ref mut y) => match x {
            &mut Err(ref mut z) => {
                let _y = y;
                let _z = z;
            }
            _ => {}
        },
        _ => {}
    };
}

fn fails(x: &mut Result<String, String>) {
    match x {
        &mut Ok(ref mut y) => match x {
            &mut Err(ref mut z) => {
                let _y = y;
                let _z = z;
            }
            _ => {}
        },
        _ => {}
    };
}

I expected either both functions to compile or both functions to fail to compile. Instead, only the fails function gives the following error:

error[E0503]: cannot use `*x` because it was mutably borrowed
  --> src/lib.rs:18:37
   |
18 |         &mut Ok(ref mut y) => match x {
   |                 ---------           ^ use of borrowed `x.0`
   |                 |
   |                 `x.0` is borrowed here
19 |             &mut Err(ref mut z) => {
20 |                 let _y = y;
   |                          - borrow later used here

For more information about this error, try `rustc --explain E0503`.

In my understanding, whether &mut Never is uninhabited is undecided. Therefore, since I'm only creating references to Never (as opposed to actually creating Never values) I would think that I wouldn't get any special casing for uninhabited types. Thus, the current behavior seems wrong to me.

Meta

Reproducible on the playground with version 1.92.0-nightly (2025-09-14 52618eb338609df44978)

[theemathas]

Might be related to #142394. Inspecting the MIR, it seems that, for the inner match in the works, there is no discriminant read to check whether x matches against &mut Err(ref mut z).

[theemathas]

Version that involves code that's actually reachable under normal circumstances:

enum Never {}

fn works(x: &mut Result<Never, (String, String)>) {
    match x {
        &mut Err((ref mut y, _)) => match x {
            &mut Err((_, ref mut z)) => {
                let _y = y;
                let _z = z;
            }
            _ => {}
        },
        _ => {}
    };
}

fn fails(x: &mut Result<String, (String, String)>) {
    match x {
        &mut Err((ref mut y, _)) => match x {
            &mut Err((_, ref mut z)) => {
                let _y = y;
                let _z = z;
            }
            _ => {}
        },
        _ => {}
    };
}

error[E0503]: cannot use `*x` because it was mutably borrowed
  --> src/lib.rs:18:43
   |
18 |         &mut Err((ref mut y, _)) => match x {
   |                   ---------               ^ use of borrowed `x.0.0`
   |                   |
   |                   `x.0.0` is borrowed here
19 |             &mut Err((_, ref mut z)) => {
20 |                 let _y = y;
   |                          - borrow later used here

For more information about this error, try `rustc --explain E0503`.

[JakobDegen]

Here's something related:

enum Single {
    V(String, String),
}

fn works(x: &mut Single) {
    match x {
        &mut Single::V(ref mut y, _) => {
            // let _d = std::mem::discriminant(x);
            match x {
                &mut Single::V(_, ref mut z) => {
                    let _y = y;
                    let _z = z;
                }
                _ => {}
            }
        },
        _ => {}
    };
}

fn fails(x: &mut Single) {
    match x {
        &mut Single::V(ref mut y, _) => {
            let _d = std::mem::discriminant(x);
            match x {
                &mut Single::V(_, ref mut z) => {
                    let _y = y;
                    let _z = z;
                }
                _ => {}
            }
        },
        _ => {}
    };
}

This one is interesting because it shows that some of this behavior is visible without uninhabited variants (the relevant condition is instead that there's only one inhabited branch)

[JakobDegen]

Copying a comment I'd left on discord answering why this happens:

If you look at the built mir for the works case (have to use -Zdump-mir=built for that, can't use playground), this is the mir that produces y:

bb5: {
        StorageLive(_4);
        _4 = &mut (((*_1) as Ok).0: Never);
        PlaceMention(_1);
        falseEdge -> [real: bb8, imaginary: bb6];
    }

And then this is the mir for the inner match:

bb8: {
        StorageLive(_5);
        _5 = &mut (((*_1) as Err).0: std::string::String);
        StorageLive(_6);
        _6 = move _4;
        FakeRead(ForLet(None), _6);
        StorageLive(_7);
        _7 = move _5;
        ...

Notice that for the inner match, there's no discriminant operation. It's just immediately setting _5 (z) to the reference to the inner field. That reference is treated as non-overlapping with the reference y (because they're from different enum variants, in borrowck this is normally completely fine) and so everything borrowchecks just fine

In the version that fails, you additionally get this in between the two snippets above:

bb5: {
        StorageLive(_4);
        _4 = &mut (((*_1) as Ok).0: std::string::String);
        PlaceMention(_1);
        _5 = discriminant((*_1));
        switchInt(move _5) -> [1: bb7, otherwise: bb6];
    }

ie it's actually re-reading the discriminant of x, and obviously that conflicts with the lifetime for y

[Nadrieril]

This should be fixed by #138961 I believe. EDIT: actually no, but it's a stepping stone. T-lang basically said "yes there should be a discriminant read in these cases", we just have to find where and finish implementing it.