Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
DanielEScherzer wants to merge 1 commit into
base: master
Choose a base branch
from
+3 −0
Open

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions src/type-layout.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -200,6 +200,9 @@ r[layout.repr.c.struct]
r[layout.repr.c.struct.align]
The alignment of the struct is the alignment of the most-aligned field in it.

r[layout.repr.c.struct.align-empty]
The alignment of a struct with no fields is 1.
Copy link
Copy Markdown
Member

@RalfJung RalfJung May 6, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

@joshtriplett joshtriplett May 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member

@RalfJung RalfJung May 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

@DanielEScherzer DanielEScherzer May 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

@Jules-Bertholet Jules-Bertholet May 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

@RalfJung RalfJung May 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the layout.repr.c.struct.align rule says

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

Then I would suggest that it makes more sense to edit that rule than add a new one. A single rule should suffice to define the alignment of the type.

Something lie:
The alignment of the struct is the maximum of the alignments of all fields, or 1 if there are no fields.

Copy link
Copy Markdown
Contributor Author

@DanielEScherzer DanielEScherzer May 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can combine the rules, no objection to that, just need T-lang to sign off on the new guarantee being added


r[layout.repr.c.struct.size-field-offset]
The size and offset of fields is determined by the following algorithm.

Expand Down
Loading