Outdated docs claim that `#[repr(transparent)]` on empty structs is not permitted

[scovich]

This code compiles:

#[repr(transparent)] struct Foo {}

Going by the docs for #[repr(transparent)]:

#[repr(transparent)] can only be used on a struct or single-variant enum that has a single non-zero-sized field (there may be additional zero-sized fields). The effect is that the layout and ABI of the whole struct/enum is guaranteed to be the same as that one field.

... it seems like the compiler should reject that code, with diagnostics similar to those it emits for an empty transparent enum:

error[E0084]: unsupported representation for zero-variant enum
 --> src/lib.rs:2:1
  |
2 | #[repr(transparent)] enum E {}
  | ^^^^^^^^^^^^^^^^^^^^ ------ zero-variant enum

error[E0731]: transparent enum needs exactly one variant, but has 0
 --> src/lib.rs:2:22
  |
2 | #[repr(transparent)] enum E {}
  |                      ^^^^^^ needs exactly one variant, but has 0

Some errors have detailed explanations: E0084, E0731.

[compiler-errors]

This regressed somewhere in 1.55

[compiler-errors]

This is intentional: #86279

[compiler-errors]

Notably, the difference between empty (variantless) enums and empty (fieldless) structs are that the former are uninhabited. Fieldless structs just have 0 size.

[compiler-errors]

Actually, is the reference out of date? 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

[compiler-errors]

We should update the reference anyways to note this change in rules. I still don't consider this to be a bug according to these rules:

#77841 (comment)

[scovich]

Yes, reading the RFC, there is no bug, but the stale documentation needs to be fixed so people are not misled.