These days, values of types like MaybeUninit are only ever represented in-memory in the interpreter; they cannot be stored in a Scalar. Only integers (that never have provenance) and pointers (that always have a single well-defined provenance) can exist as Scalar.
This does give us a chance to represent "partial pointers", so that we could support people writing their own memcpy in const that works by copying MaybeUninit<u8> in a loop. I don't know if there's any real usecase for this, but it seems neat. :D
The main challenge is that we have to ensure that when the bytes of a pointer get put back together, that they all appear in the right order. This is not a constraint that our current per-byte provenance system supports, and I doubt that we want to put such a constraint onto regular runtime semantics. We'd also have to report an error if such a pointer fragment byte makes it into the final value of a constant, since AFAIK we can't represent them in LLVM.
These days, values of types like
MaybeUninitare only ever represented in-memory in the interpreter; they cannot be stored in aScalar. Only integers (that never have provenance) and pointers (that always have a single well-defined provenance) can exist asScalar.This does give us a chance to represent "partial pointers", so that we could support people writing their own
memcpyin const that works by copyingMaybeUninit<u8>in a loop. I don't know if there's any real usecase for this, but it seems neat. :DThe main challenge is that we have to ensure that when the bytes of a pointer get put back together, that they all appear in the right order. This is not a constraint that our current per-byte provenance system supports, and I doubt that we want to put such a constraint onto regular runtime semantics. We'd also have to report an error if such a pointer fragment byte makes it into the final value of a constant, since AFAIK we can't represent them in LLVM.