-
Notifications
You must be signed in to change notification settings - Fork 498
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
base: master
Are you sure you want to change the base?
Spec: Improve Definition of Type Layout #1654
Conversation
This reverts commit 9b9226c.
…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>.
…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>.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r[layout.repr.rust.option.elligible] | |
r[layout.repr.rust.option.eligible] |
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*. |
There was a problem hiding this comment.
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`. |
There was a problem hiding this comment.
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.
This improves the definition of Type Layout to be more formal. The following changes are made:
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.result_ffi_guarantees
rust#130628) is documented.repr(C)
layouts are consolidated, though the section onstruct
s 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 ofrepr(C)
as applied tostruct
s 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.