Structs with no fields or all-ZST fields are ZSTs

[DanielEScherzer]

Guarantee that structs with Rust representation and with no fields, or where all fields are ZSTs, are themselves ZSTs.

Guarantee that enums with Rust representation with a single struct-like variant with no fields, or where all fields are ZSTs, are themselves ZSTs.

[traviscross]

cc @RalfJung @rust-lang/opsem

[theemathas]

Seems bizarre to guarantee this for struct-like variants but not unit-like variants or tuple-like variants.

View changes since the review

[RalfJung]

That seems reasonable to me (specifically for repr(Rust); not necessarily for other reprs). Someone should check whether it is honored by -Zrandomize-layout.

[traviscross]

We talked about this in the lang call today. Let's propose to do this with the correction that, for enums, we mean those repr(Rust) enums without a primitive representation specified and that have a single field-struct-like variant, a single unit-struct-like variant, or a single tuple-struct-like variant where the struct-like thing has no fields or where all of the fields are zero-sized.

@rfcbot fcp merge lang

[rust-rfcbot]

@traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• check-randomize-layout resolved by Structs with no fields or all-ZST fields are ZSTs #2262 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

@rfcbot concern check-randomize-layout

[tmandry]

This seems stronger than what we guarantee for non-ZST structs, which require #[repr(transparent)] to have the same representation as the inner type. In the lang meeting, @steffahn pointed out that the non-ZST case is harder because certain types get passed in registers, etc.

I don't see a reason not to make this guarantee, and it seems like a useful one, so let's do it.

@rfcbot reviewed

[zachs18]

Should we also guarantee that zero-variant repr(Rust) enums are ZSTs? They currently are in practice.

---

Someone should check whether it is honored by -Zrandomize-layout.

Yes, I believe it is. IIUC the current implementation of -Zrandomize-layout only reorderes fields, never introduces any "extra" padding¹. Shuffling the field order cannot make a ZST into a non-ZST (or vice versa), so the current implementation upholds the proposed guarantees.

reasoning

When the -Zrandomize-layout flag is enabled, the compiler enables ReprFlags::RANDOMIZE_LAYOUT for types defined in that crate (src) (unstable_opts.randomize_layout is not mentioned anywhere else in the compiler).

ReprFlags::RANDOMIZE_LAYOUT is mentioned in four places in the compiler:

1. When it is declared (src)
2. When it is enabled (see previous section)
3. In SizeSkeleton, which IIUC ignores it when computing the size of generic NPO-optimized enums and newtype structs/enums (src)
   1. NPO is irrelevant here (there are no ZSTs eligible for NPO optimization)
   2. For newtypes over ZSTs, this should correctly give a ZST size regardless of RANDOMIZE_LAYOUT
4. When it is used in ReprOptions::can_randomize_type_layout which returns !self.inhibit_struct_field_reordering() && self.flags.contains(ReprFlags::RANDOMIZE_LAYOUT) (src)

ReprOptions::can_randomize_type_layout is used in one place in the compiler: in layout computation (fn univariant_biased) where the field list (excluding the unsized tail) is shuffled if it returns true (instead of being optimized by sorting by alignment) (src). Shuffling (or sorting) the field order cannot make a ZST into a non-ZST (or vice versa), so the current implementation upholds the proposed guarantees.

I opened a PR rust-lang/rust#157905 to update the comments in some of the places where -Zrandomize-layout is implemented referring back to this FCP to ensure that future changes to -Zrandomize-layout do not break these guarantees.

@/rustbot label I-lang-nominated

~~Nominating for possibly resolving the -Zrandomize-layout concern (and maybe considering zero-variant repr(Rust) enums) ~~

Footnotes

1. other than the padding necessary to make fields aligned, and since 0 is a multiple of any alignment, this padding is never added for struct-like layouts if all fields are zero-sized ↩

[rustbot]

Error: Label I-lang-nominated can only be set by Rust team members

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[traviscross]

@rfcbot resolve check-randomize-layout

Thanks @zachs18. I looked into this and concur.

Should we also guarantee that zero-variant repr(Rust) enums are ZSTs? They currently are in practice.

Probably. Let's do that in a separate Reference PR.

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[DanielEScherzer]

We talked about this in the lang call today. Let's propose to do this with the correction that, for enums, we mean those repr(Rust) enums without a primitive representation specified and that have a single field-struct-like variant, a single unit-struct-like variant, or a single tuple-struct-like variant where the struct-like thing has no fields or where all of the fields are zero-sized.

If/when FCP passes I'll apply this correction

[traviscross]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[chorman0773]

without a primitive representation specified

This wording doesn't seem super clear on whether or not repr(C) enums are excluded (which they should be, because they are implicitly repr(C, Int), where Int is a target-specific integer type, but that isn't "specified" in the repr attribute).

[DanielEScherzer]

We talked about this in the lang call today. Let's propose to do this with the correction that, for enums, we mean those repr(Rust) enums without a primitive representation specified and that have a single field-struct-like variant, a single unit-struct-like variant, or a single tuple-struct-like variant where the struct-like thing has no fields or where all of the fields are zero-sized.

If/when FCP passes I'll apply this correction

Done, fa61cbd

@rustbot ready

[DanielEScherzer]

without a primitive representation specified

This wording doesn't seem super clear on whether or not repr(C) enums are excluded (which they should be, because they are implicitly repr(C, Int), where Int is a target-specific integer type, but that isn't "specified" in the repr attribute).

In the glossary, the new entries start with - `repr(Rust)` [structs] and - `repr(Rust)` [enums] s so I think it is clear there

On the type layout page, the entries are under the ### The `Rust` representation section heading; the other layout rules there don't explicitly note that they are for the rust representation because that is clear from the location and context