Repository navigation
Unions interacting with Enum layout optimization #36394
Description
IRC (#rust) short discussion log, since I don't actually know much about this:
19:30 Amanieu: bluss: I had a look at nodrop-union, shouldn't you add another field to union with type () to inhibit the enum layout optimization?
19:31 Amanieu: admittedly the exact interactions between enums and unions is still somewhat poorly specified
19:31 bluss: Amanieu: good question. As it is now, that optimization is not used for unions
19:31 bluss: Amanieu: but I haven't checked the RFC discussions to see how it's going to be
19:32 Amanieu: I don't think this point was covered in the discussions
19:33 Amanieu: well, someone should probably open an issue about it
19:33 Amanieu: it's 2am here so I'll let someone else do that :P
19:34 bluss: it's 3am here, so I'm passing it on
Activity
Amanieu commentedon Sep 11, 2016
Some specific examples:
The question here is essentially, what is the size of
Option<A>? Should the enum layout optimization apply, in which case it is just 1 pointer length? Or should it act likeOption<B>, where the()inhibits this optimization and forces the use of a separate enum tag. The key point here is that the optimization requires all union variants to beNonZero, which is not the case for().bluss commentedon Sep 11, 2016
Previous discussion (11 April - 28 May) rust-lang/rfcs#1444 (comment)
bluss commentedon Sep 11, 2016
union Bcould use the layout optimization just as well asunion A, since B's()member has padding bytes where the discriminant would want to be placed.nagisa commentedon Sep 11, 2016
Layout of non-
#[repr(C)]unions is unspecified, just like the layout of any other ADT. If you want any layout guarantees, I’d recommend sticking to#[repr(C)]for now.bluss commentedon Sep 11, 2016
This is another open question for the tracking issue: #32836
bluss commentedon Oct 8, 2016
@nagisa While repr(C) fixes the representation of a type Foo, it does not say anything (that I know to be documented) about the representation of
None::<Foo>, i.e types composed of Foo.joshtriplett commentedon Jan 2, 2017
@Amanieu unions don't have a discriminant, though, so all three unions should have the size of a pointer.
Adding a
()to a union should never add any size to the union, because it adds zero bits of information. You can always interpret a union as any type you want, and you need 0 bits to identify the 1 possible value of type().I don't think the enum layout optimization needs to apply here at all; the size of a union should always match the maximum size of any field type.
nagisa commentedon Feb 2, 2017
Why do you care about representation of
Option<T>? It isrepr(Rust)and therefore unpecified.Mark-Simulacrum commentedon May 20, 2017
I think that this discussion has come to the conclusion that unions interact "as all other things" with enum layout optimization, and I'm going to close.
SimonSapin commentedon May 20, 2017
I think this issue should be re-opened.
It is originally about the nodrop-union crate, which is pretty much the same as
std::mem::ManuallyDrop. The problem is that both of these types:Drop. They may or may not containNonZero<_>(or something else that might qualify for future enum layout optimizations).They need not only a way to inhibit automatic drop glue (which
unionis already guaranteed to do) but also stop enum layout optimization “from the outside” from peeking “inside” them (whichunionhappens to do in the current implementation, but maintaining that doesn’t seem agreed-upon).Concretely,
ManuallyDropneeds to be written in some way (whether that’s#[repr(C)], adding a()variant, or something else) such that this code is guaranteed not to read uninitialized memory:More generally, we need to have principles for what to do to use
std::mem::uninitializedsafely in a generic context.std::mem::ManuallyDropis probably part of that story.Mark-Simulacrum commentedon May 20, 2017
Hm, okay. I'll reopen; this was (or is? Was it merged?) an unresolved question in the RFC.
SimonSapin commentedon May 20, 2017
Could you point to a specific part of the RFC? I can’t find it in rust-lang/rfcs#1897.
Mark-Simulacrum commentedon May 20, 2017
I don't think the original union RFC mentioned it (RFC 1444), but there was some discussion in the thread itself: rust-lang/rfcs#1444 (comment) and rust-lang/rfcs#1444 (comment) (but also just search from "enum layout")
SimonSapin commentedon May 20, 2017
Ah, found rust-lang/rfcs#1444 (comment) which concludes that adding a
()field/variant inhibits enum layout optimization. But then #36394 (comment) says the opposite.petertodd commentedon May 7, 2019
Just an update: at present
MaybeUninit<T>depends on()inhibiting enum layout optimization to make constructs like the following safe:RalfJung commentedon May 18, 2019
Also see rust-lang/unsafe-code-guidelines#73: discussion of the invariant that a union has to satisfy at all times. This directly informs which layout optimizations are possible.
Rollup merge of rust-lang#60590 - petertodd:2018-test-union-nonzero, …