Change:
} }; <del> let discr = self.project_field(bx, discr_index); let lldiscr = bx.load_operand(discr).immediate(); </del> <ins> // Read the tag/niche-encoded discriminant from memory. let encoded_discr = self.project_field(bx, discr_index); let encoded_discr = bx.load_operand(encoded_discr); // Decode the discriminant (specifically if it's niche-encoded). </ins> match *discr_kind { layout::DiscriminantKind::Tag => { let signed = match discr_scalar.value {

Discussion:
Playground link: <details<summaryClick to see the example code from above link </summary</detailsExpected output: Actual output: Running the above code on both Rust stable and nightly on my machine returns with some number different on each run prefixing the output. Some experimentations: Implementing variants for enum solves this issue. Remove variants and solves this issue. Use any variant of other than works. I assume this is a bug in the compiler?
cc since potentially has something to do with enum optimizations?
Minimized: MIR: Debug ASM (does not reproduce with release profile): <details</details
Regression between 1.23.0 and 1.24.0
This seems like a rather serious soundness hole that I would suggest treating as P-high. cc
Given LLVM for the interesting code is:
This is probably not A-LLVM because the generated LLVM IR is already wrong.
MIR still looks okay to me, so this seems like a MIR -LLVM-IR translation bug.
I edited the code snippet – the reproducer above in the comments has changed in the time I was looking at things and I blindly copied it.
Much better, thanks! should be "rebasing" the the integers in memory to the discriminants, which would require subtracting , not , so maybe it's "just" an off-by-one? EDIT: yeah the subtraction should be with , should be :
"More minimized" without match and unstable features: Interesting enough: When one removes the in the enum, the MIR code is still the very same, but it does not print the line. The LLVM-IR changes from to ( and vs ).
triage: P-high. Leaving nominated and unassigned for now.
I compared what miri does (which doesn't fail) against what codegen does. The relevant difference is vs where the latter (codegen) does not check whether . Other than that, both code paths are equivalent I'd guess that's just a result from other niche optimizations kicking in for the enum without .
I think I've figured out what's wrong here, why this wasn't triggered more often, and why is needed.

What we have is an , with 4 variants: contains the (which uses and , so will be ) is excluded because it's uninhabited and are the I was confused because initially I thought would be included and therefore would be - but no, it's ! So the codegen of the instruction is correct, should be . The reason this hasn't caused many problems in the past is that has always been (if the dataful variant is the first one) or (otherwise), if no variant is uninhabited. Currently, the check is: But the correct one-comparison trick, which I meant to use, would be: That is, you have to* rely on rebasing the lowest value in the range to , for this to work. What miri does is less efficient, but that's fine, as it's an interpreter. For codegen we want something simple.
What Miri does is correct though? Including considering both and as inclusive bounds?
is equivalent to (assuming unsigned integers). This is because everything in will be shifted over to and becomes . And it would've worked, too, if I hadn't combined a different operation into it, ruining the trick. Oh and miri should probably be using on a range, ideally the one from the layout.
I tried, it doesn't really make things nicer and I am not even sure if moving the assertions around is correct: Probably it's not. The actually is , so comparing that with again is anyway a bit funny. EDIT: Also that arithmetic is done at type , is that even correct?
Hmm, the arithmetic probably needs to be done on the size of the discriminant, like here: Double-casting assertions can, and probably should, be replaced nowadays by . Otherwise, your changes are in the right direction, IMO.
I am not so convinced... seems like the is a , but the discriminant may be way bigger, so probably casting things down before we know that it is in the "niche range" is wrong? This avoids casting too early, but it's not really any safer than what we do right now:
triage: assigning to
I was going to argue that the bug is older, but 1.23 was early 2018, and the bug was introduced late 2017, as the code in question has been wrong in the same way since .

So yeah, a 2-year-old codegen bug.
noted that issue appears under control at T-compiler meeting, and deliberately skipped discussion of it. Removing nomination label.