Possible codegen regression when matching against nested enums

[anp]

Code

I tried this code (reduced from a much larger test):

fn main() {
    let output = OpenResult::Ok(());
    match output {
        OpenResult::Ok(()) => (),
        _ => unreachable!("this won't be reached"),
    }
    match output {
        OpenResult::Ok(()) => (),
        _ => unreachable!("somehow matching twice is the trick"),
    }
}

enum OpenResult {
    Ok(()),

    // we don't produce either of these variants but both are necessary to trigger the issue
    #[allow(dead_code)]
    Err(()),
    #[allow(dead_code)]
    TransportErr(TransportErr),
}

#[allow(dead_code)] // don't need to produce this to repro
#[repr(i32)]
enum TransportErr {
    UnknownMethod = -2,
}

(playground)

I expected to see this happen: runs with 0 exit code and no output

Instead, this happened:

thread 'main' panicked at 'internal error: entered unreachable code: somehow matching twice is the trick', src/main.rs:9:14

Version it worked on

This code works on stable and beta, and as recently as a3c0a02.

Version with regression

This reproduces with the 2022-11-16 nightly on the playground. cargo-bisect-rustc suggests this was introduced by #102872.

@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged

[Noratrieb]

That looks like a real miscompilation :(
cc @mikebenfield

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[mikebenfield]

I've found the problem; it is indeed an issue with my code in codegen_get_discr. I'll have a PR with a fix some time today.

[apiraino]

Since there is some work in progress to fix this:

@rustbot assign @mikebenfield