JumpThreading is confused by an extraordinary use of SetDiscriminant

[tmiasko]

#![feature(custom_mir)]
#![feature(core_intrinsics)]
use std::intrinsics::mir::*;

enum E { A, B(char) }

#[custom_mir(dialect = "runtime")]
pub fn f() -> usize {
    mir!(
        let a: isize;
        let e: E;
        {
            e = E::A;
            SetDiscriminant(e, 1);
            a = Discriminant(e);
            match a {
                0 => bb0,
                _ => bb1,
            }
        }
        bb0 = {
            RET = 0;
            Return()
        }
        bb1 = {
            RET = 1;
            Return()
        }
    )
}

fn main() {
    assert_eq!(f(), 0);
}

$ rustc c.rs -Zmir-opt-level=0 && ./c
$ rustc c.rs -Zmir-opt-level=0 -Zmir-enable-passes=+JumpThreading && ./c
thread 'main' panicked at c.rs:33:5:
assertion `left == right` failed
  left: 1
 right: 0
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

cc @cjgillot

Meta

rustc --version --verbose:

rustc 1.77.0-nightly (595bc6f00 2024-01-05)
binary: rustc
commit-hash: 595bc6f00369475047538fdae1ff8cea692ac385
commit-date: 2024-01-05
host: x86_64-unknown-linux-gnu
release: 1.77.0-nightly
LLVM version: 17.0.6

[cjgillot]

TIL that SetDiscriminant does not always set the discriminant, depending on the exact layout. It's a pity that we do not have a round-trip here. This implies that we can never thread on SetDiscriminant.

I'm preparing a PR to fix the opt.

But I really think we should amend the semantics to guarantee in polymorphic context that discriminant(x) yield d after a call to SetDiscriminant(x, d).

[tmiasko]

We can restrict SetDiscriminant to coroutines (they don't suffer from this issue since they don't use niche encoding).