Skip to content
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.

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

Spec: Improve Definition of Type Layout #1654

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

chorman0773
Copy link
Contributor

This improves the definition of Type Layout to be more formal. The following changes are made:

  • The guarantees of repr(Rust) structs and unions are defined in a separate section, as they apply to all structs and unions, even when they have another representation.
  • The layout of repr(Rust) enums is documented, with some permissions granted conservatively to implementations (like not including uninhabited variants in the size/alignment of the enum), pending approval either way.
    • I'm not too attached to including these, but omitting them could be taken as a prohibition against them in the future.
  • Discriminant Elision (now guaranteed by Finish stabilization of result_ffi_guarantees rust#130628) is documented.
  • The repr(C) layouts are consolidated, though the section on structs is left presently. I'm not sure whether to get rid of it or replace it with a large note admonition, because it isn't needed as normative text, but the definition of repr(C) as applied to structs can be confusing on its own.

I think there's some more work to be done on the chapter, but I think this is a reasonable set of stuff to do in one PR, specifically targetted at the repr attribute.

@chorman0773 chorman0773 added A-type-layout Area: type layout T-spec Team: spec labels Oct 17, 2024
@chorman0773
Copy link
Contributor Author

Link check errors are intentional in bea8b9d - I link to sections from #1618 and omitted the footnot references so it can be reverted when #1618 is merged.

@chorman0773 chorman0773 mentioned this pull request Oct 21, 2024
@chorman0773 chorman0773 added the S-waiting-on-review Status: The marked PR is awaiting review from a maintainer label Nov 10, 2024
jieyouxu added a commit to jieyouxu/rust that referenced this pull request Nov 23, 2024
…ieyouxu

Add language tests for aggregate types

This adds some tests for struct and union types, ensuring that they satisfy the rules for all structs and unions - namely that fields of structs do not overlap, fields are well-aligned, and the size of the entire.

The reference annotations used are from rust-lang/reference#1654, though the rules tested here were FCPed in <rust-lang/reference#1152>.
jieyouxu added a commit to jieyouxu/rust that referenced this pull request Nov 23, 2024
…ieyouxu

Add language tests for aggregate types

This adds some tests for struct and union types, ensuring that they satisfy the rules for all structs and unions - namely that fields of structs do not overlap, fields are well-aligned, and the size of the entire.

The reference annotations used are from rust-lang/reference#1654, though the rules tested here were FCPed in <rust-lang/reference#1152>.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 23, 2024
Rollup merge of rust-lang#133355 - chorman0773:spec-layout-tests, r=jieyouxu

Add language tests for aggregate types

This adds some tests for struct and union types, ensuring that they satisfy the rules for all structs and unions - namely that fields of structs do not overlap, fields are well-aligned, and the size of the entire.

The reference annotations used are from rust-lang/reference#1654, though the rules tested here were FCPed in <rust-lang/reference#1152>.
the same as the order in which the fields are specified in the declaration of
the type.
r[layout.repr.rust.option.intro]
Certain `repr(Rust)` enums are specially layed out when used with certain types. This layout process is known as discriminant elision.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Certain `repr(Rust)` enums are specially layed out when used with certain types. This layout process is known as discriminant elision.
Certain `repr(Rust)` enums are specially laid out when used with certain types. This layout process is known as discriminant elision.

Be aware that the second guarantee does not imply that the fields have distinct
addresses: zero-sized types may have the same address as other fields in the
same struct.
r[layout.repr.rust.option.elligible]
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
r[layout.repr.rust.option.elligible]
r[layout.repr.rust.option.eligible]

Comment on lines +280 to +289
r[layout.repr.rust.option]

r[layout.repr.rust.field-storage]
The second guarantee means that the fields can be
ordered such that the offset plus the size of any field is less than or equal to
the offset of the next field in the ordering. The ordering does not have to be
the same as the order in which the fields are specified in the declaration of
the type.
r[layout.repr.rust.option.intro]
Certain `repr(Rust)` enums are specially layed out when used with certain types. This layout process is known as discriminant elision.

Be aware that the second guarantee does not imply that the fields have distinct
addresses: zero-sized types may have the same address as other fields in the
same struct.
r[layout.repr.rust.option.elligible]
An `enum` type is a *discriminant elision eligible* enum if:
* It has exactly two variants,
* One variant has exactly one field, known as the *elision candidate field*, and
* The other variant has no fields that have size greater than 0 or alignment greater than 1, known as the *elided variant*.
Copy link
Member

Choose a reason for hiding this comment

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

It is slightly confusing when this suggests the variant is "elided". It is not: it requires a concrete, physical encoding of some kind for the discriminant. Instead, the rule here imposes a constraint on how that encoding is performed, which forces it to be encoded in a way that the resulting enum matches the ABI of another type.

The discriminant's encoding, ultimately, will still occupy that physical bitpattern.

* A `struct`, other than [`core::cell::UnsafeCell<T>`], defined using [`repr(transparent)`][layout.repr.transparent], which has a field that is an *elision candidate*, and all other fields have size 0 and alignment 1.

r[layout.repr.rust.option.elision]
If the *elision candidate field* of a *discriminant elision eligible* `enum` has an *elision candidate type*, then the `enum` has the same layout as that field, except that the value consisting of all `0` bytes represents the *elided variant* of the `enum`.
Copy link
Member

Choose a reason for hiding this comment

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

This part is strictly incorrect. It will have the associated value, determined by the "inner type" T, as T-lang has already FCPed a type that is all-0xFF bytes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-layout Area: type layout S-waiting-on-review Status: The marked PR is awaiting review from a maintainer T-spec Team: spec
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants