Semantics of SetDiscriminant with niched variants

[RalfJung]

This is motivated by rust-lang/rust#119674:

For a type like enum E { A, B(char) }, currently SetDiscriminant(place, 1) is just a NOP, since niche-encoded variants do not need to store the discriminant explicitly.

However, that means that SetDiscriminant; Discriminant doesn't necessarily return the just-written discriminant, even for enums: we might be calling SetDiscriminant(place, 1) on a place that doesn't actually carry the niched value, but it remains a NOP. That seems unfortunate.

I think it'd make sense if SetDiscriminant on niched variants were to do the equivalent of read_discriminant, and cause UB if the already encoded discriminant does not match the niched variant.

Cc @cjgillot @tmiasko

[tmiasko]

SetDiscriminant is only used for coroutines. Unless there are plans to reintroduce it for ADTs, I would go in the direction of restricting it to coroutines and eventually replacing it with a field access.

[RalfJung]

SetDiscriminant is only used for coroutines.

That's news to me. Since when? How are enum variants set?

[cjgillot]

As we do not deaggregate ADTs any more, we only construct enum variants using an aggregate assignment. So rustc does not produce SetDiscriminant on enums any more.

[RalfJung]

Oh I see. Internally in the MIR semantics that will still be a bunch of assignments followed by SetDiscriminant though... but it's probably impossible to hit the "bad" case that way.

Still, having SetDiscriminant "verify" the discriminant it wrote makes a lot of sense to me.

[RalfJung]

Still, having SetDiscriminant "verify" the discriminant it wrote makes a lot of sense to me.

rust-lang/rust#120882 implements that in Miri.