Guarantee the layout of some unions having a single non-zero-sized field

[gnzlbg]

This PR guarantees that unions having a single non-zero-sized field have the same layout as that field if:

• that field has no padding,
• all zero-sized fields have an alignment requirement of 1.

Without the requirement that the field might have no padding, the union would "inherit" the padding of their non-zero-sized field, such that these unions wouldn't be "bags of bits".

We can relax this requirement later if we decide that unions shouldn't just be bags of bits, but for the time being, requiring no padding allows us to make this guarantee.

Right now, we don't consider padding to be a part of layout. We should probably do so, since for unions padding doesn't really relate to field offsets - e.g., for repr(C) unions it results from the "overlapping" padding of their fields and trailing padding, see #160.

An alternative way to word the no padding requirement here would be to guarantee this only for types with a "call ABI" equal to "Scalar" or "Vector", since those types have no padding. cc @eddyb

[RalfJung]

all zero-sized fields have an alignment requirement of 1.

This is another place where we should use the "ZST1" terminology.

[RalfJung]

We have not defined padding (what it is, how it behaves, where it occurs in which types) anywhere, and IMO it is not part of layout. So I feel like we are getting a little ahead of ourselves here.

Padding is IMO part of the value representation of a type; no interpretation of layout (size, align, niche, call ABI, field offsets) really includes "padding". For structs it naturally emerges as the "gaps between" fields, for enums I have no idea and for unions I am confused. ;)

[gnzlbg]

So we touched this on the meeting today. And it is not clear whether we have the definitions required to word this yet. We do not have a definition for padding, it is unclear whether a definition for padding is needed, but we could try to word this without using the "term" padding with the definitions that we have, and if we can't, we might be able to identify whatever definitions would be required to word something like this (and block this on working on those).

[RalfJung]

Without the requirement that the field might have no padding, the union would "inherit" the padding of their non-zero-sized field, such that these unions wouldn't be "bags of bits".

We can say they have the same size+align, but niches and callABI might be different. Then we can avoid talking about padding, which I would prefer.

[gnzlbg]

So i've pushed a couple of commits that add pictures and make some progress.

The issues with talking about "padding" in the guarantee about Rust unions with a single non-zero sized field are unfortunate. I think that the next step for this PR would be to also write down what could we guarantee if the non-zero-sized field were to have padding bits (e.g. only size and alignment) and why (i.e. write down the rationale) - this should help refresh everybody's memory about what the constraints are.

[RalfJung]

Can we wait with this PR until after landing the other union layout one? They look like they will heavily conflict anyway.

[gnzlbg]

Yes I'd prefer to merge the other one first and then rebase this one and see if it still makes sense in its current form.

[RalfJung]

In fact I'd prefer to stage this: first just add "pictures" without saying more than we did before. That's basically an editorial change. Then try to say more.

The "picture" part should be roughly synced with #186.

[gnzlbg]

So I've rebased and solved the open issues.

[RalfJung]

LGTM. Thanks!

[hanna-kruppe]

One nit but otherwise LGTM