repr(transparent) on generic type skips "exactly one non-zero-sized field" check

[mahkoh]

#[repr(transparent)]
struct X(()); // ERROR: needs exactly one non-zero-sized field, but has 0

But

#[repr(transparent)]
struct X<T>(T);

println!("{}", mem::align_of_val(&X(())));  // 1
println!("{}", mem::size_of_val(&X(())));   // 0

The reference says

The transparent representation can only be used on a struct or an enum with a single variant that has:

• a single field with non-zero size, and
• any number of fields with size 0 and alignment 1 (e.g. PhantomData).

I do not see a reason for this restriction. Maybe simply replace "a single" by "at most one" and remove the check.

[mahkoh]

Marked as bug because people might assume X<T> values have size > 0 in unsafe code. Unlikely to be the case in real code.

[RalfJung]

I do not see a reason for this restriction. Maybe simply replace "a single" by "at most one" and remove the check.

Agreed.
Cc @rust-lang/wg-unsafe-code-guidelines

[nikomatsakis]

Discussed in the @rust-lang/lang meeting.

• We agree with the sense of this but would like a specific semantics -- i.e., if all fields are ZSTs, then we need to define what the ABI behavior of the type is (if there is a single non-ZST field f, then it behaves like f, the "real value" -- but what does it act like if there are no real values?).
• Perhaps the answer is just "whatever happens if you try to pass ()".
• If someone can supply a concrete rule that makes sense, we would like to approve it =)

[nikomatsakis]

To clarify:

I do not see a reason for this restriction. Maybe simply replace "a single" by "at most one" and remove the check.

This removes a restriction, but it now allows a new possibility that didn't exist before, so what are the rules meant to be for that case? (Well, it did exist because of generics, but presumably the rules didn't expect it to exist.)

[chorman0773]

A possible rule is to use the ABI of the first 1-ZST Field if there are no non 1-ZST fields.
One question I have, what about types with size 0 and alignment >1 (0 sized arrays like [u16;0] are examples). Under this rule, these types would still seem to be excluded. That could probably be added to the first part at the same time as it's lifted to allow zero of such types. If a ZST that has an alignment >1 is in a repr(transparent) struct, the ABI follows that ZST specifically.

[RalfJung]

AFAIK "zero-sized-field" for repr(transparent) means 1-ZST. Everything else would be buggy I think...

So a ZST with alignment greater 1 behaves like a non-ZST. I don't think that should change.

[chorman0773]

AFAIK "zero-sized-field" for repr(transparent) means 1-ZST

If it's already permitted, that's brillaint. In which case my point can be reduced to a point of clarification, it would be good if the documentation noted that ("At most one non-zero-sized field or zero-sized field with an alignment greater than 1", wording could probably be changed, I'm much better writing normative text than text for users). If its not already permitted, adding it seems to be an extension of what is being discussed here.

[RalfJung]

It's not a permission though, it's a restriction? For example, the following type is rejected, as it should:

#[repr(transparent)]
struct Test((), i32, [i32; 0]);

[RalfJung]

On the other hand, this is also rejected:

#[repr(transparent)]
struct Test((), [i32; 0]);

Even though it has exactly one non-1-ZST field. So looks like the actual check is more something like

• All fields except for 1 must be zero-sized
• And additionally all zero-sized fields must have alignment 1

[chorman0773]

On the other hand, this is also rejected

This is what my point is. If we permit transparent types with only ZST's, it seems like it would be equally inconsistent if we don't allow a transparent type with exactly one ZST that isn't a 1-ZST (and any number of 1-ZSTs). The consistency issue raised above would apply here, if it's possible to have a generic transparent type which is monomorphized with [i32;0], but its not permitted to include [i32;0] directly, even if all other fields are 1-ZSTs.

[RalfJung]

The consistency issue raised above would apply here, if it's possible to have a generic transparent type which is monomorphized with [i32;0], but its not permitted to include [i32;0] directly, even if all other fields are 1-ZSTs.

Fully agreed.