New rule layout.repr.c.struct.align-empty

[DanielEScherzer]

No description provided.

[RalfJung]

We are moving towards repr(C) being defined entirely by the platform ABI (rust-lang/rfcs#3845). So I'm not sure we should add any such promises.

[joshtriplett]

We talked about this in today's @rust-lang/lang call. Our understanding of the migration plan is that that we'll be adding a today's-edition name for repr(C) (whatever that ends up being named), adding repr(ordered_fields) which will be the same (but indicates that the user explicitly wants that rather than being auto-migrated), and then adding a new repr(C) for the new edition.

Given that transition plan, our understanding is that all the current documentation of repr(C) will move to be documentation of the today's-edition repr(C) and repr(ordered_fields), and then we'll add new documentation for the new repr(C) that largely says we do whatever the platform C ABI does.

Given that transition plan, do you see an issue with this proposal as ongoing documentation of what will end up being the old repr(C) rather than the new one, assuming that all this documentation moves to being for the old one?

[RalfJung]

For what might eventually be called repr(ordered_fields), this new clause is indeed correct.

It's also redundant though, it follows from the definition of the layout algorithm.

[DanielEScherzer]

This rule was proposed in the context of discussing #2243 on the t-lang-docs call yesterday where it was concluded that it does not actually follow from the definition of the layout algorithm - the size and offsets algorithm doesn't describe how to identify the alignment of the type, and the layout.repr.c.struct.align rule says

The alignment of the struct is the alignment of the most-aligned field in it.

but if there are no fields then there is no most-aligned field

[Jules-Bertholet]

Our understanding of the migration plan is that that we'll be adding a today's-edition name for repr(C) (whatever that ends up being named), adding repr(ordered_fields) which will be the same

FWIW, I don't think that end state is set in stone. E.g. to resolve rust-lang/rust#112480, we might potentially end up at a state where all 3 of old repr(C), new repr(C), and repr(ordered_fields) are different.