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.

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

Jump to bottom

Specify guarantees for repr(rust) structs #1152

Merged
merged 7 commits into from
Sep 19, 2022
Merged

Specify guarantees for repr(rust) structs #1152

Changes from 2 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
5a8a664
Specify guarantees for repr(rust) structs
Darksonn Jan 31, 2022
e9a1ddf
Address review
Darksonn Feb 6, 2022
377c524
Fix typo
Darksonn Mar 22, 2022
f9ec1d2
Be less struct-centric
Darksonn May 9, 2022
1275bcc
Rephrase layout of tuples
Darksonn May 9, 2022
3ecc681
Remove stray 'minimum'
Darksonn May 9, 2022
1ae7c2d
Link to default representation.
ehuss Sep 19, 2022
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
26 changes: 23 additions & 3 deletions src/type-layout.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,9 +86,10 @@ String slices are a UTF-8 representation of characters that have the same layout

## Tuple Layout

Tuples do not have any guarantees about their layout.
Tuples have the same layout guarantees as a struct with the same fields when
Copy link
Member

Choose a reason for hiding this comment

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

I'm opposed to documenting this, as it precludes us from tuple variadic approaches which require "tail borrowing."

Copy link
Member

Choose a reason for hiding this comment

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

@rfcbot concern tuple-tail-borrowing

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can you elaborate on what that is?

Copy link
Member

Choose a reason for hiding this comment

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

There have been a number of discussions in relation to variadic generics about wanting the ability to write code which could recurse over the structure of a tuple, HList-style. In order for this to work, the "tail" of a tuple must be represented contiguously. That is, for tuple (A, B, C, D), there must be a sub-tuple (B, C, D) in memory. Allowing arbitrary ordering as structs do would cause layouts like (A, D, C, B), from which it's impossible to create a reference to a tuple of a sub-structure like (B, C, D).

Note that hlist-compatible representations of tuples need not be strictly ordered-- it's fine for each new element to be placed at either the front, back, or even inside of the tuple so long as the tail tuple remains a part of the representation.

I'd like our representation documentation to stay forward-compatible with tuple tail-borrowing until we've explicitly decided not to do it so that users aren't expecting to be able to transmute between struct S(A, B, C, D); and tuple (A, B, C, D).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As I intended the guarantees I have written, what you described here would still be backwards-compatible to introduce, because that particular ordering is just one among the many different orderings that the guarantees allow the compiler to choose. As for the struct, you also can't transmute between different #[repr(Rust)] structs with the same fields either.

I would be happy to elaborate on this in the text though.

Copy link
Member

Choose a reason for hiding this comment

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

I see, I misunderstood "have the same layout guarantees as a struct with the same fields". I over-read this to mean "have the same layout as a struct with the same fields". Thanks for clarifying! Still, I can imagine this documentation going stale: if we provide more guarantees for structs in the future, we wouldn't necessarily match those guarantees for tuples.

Copy link
Contributor

Choose a reason for hiding this comment

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

I tend to think that tuples and tuple structs ought to have analogous layout. The UCG conversation at least came to that conclusion (we do discuss "tail references" as well). There was talk, as I recall, of making (T, T, T) sort of special case, to permit casting that to [T; 3].

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What do you think of the new phrasing?

laid out according to the default struct representation.

The exception to this is the unit tuple (`()`) which is guaranteed as a
The exception to this is the unit tuple (`()`), which is guaranteed as a
zero-sized type to have a size of 0 and an alignment of 1.
Comment on lines +91 to 92
Copy link
Member

Choose a reason for hiding this comment

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

Does the former statement imply this statement?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not as I wrote it here, but you could certainly argue that it should be changed so it does.


## Trait Object Layout
Expand Down Expand Up @@ -162,7 +163,26 @@ representation will not change the layout of `Inner`.
Nominal types without a `repr` attribute have the default representation.
Informally, this representation is also called the `rust` representation.

There are no guarantees of data layout made by this representation.
The only data layout guarantees made by this representation are those required
for soundness. They are:

1. The fields of the struct are properly aligned.
Darksonn marked this conversation as resolved.
Show resolved Hide resolved
2. The fields do not overlap.
3. The minimum alignment of the struct is at least the maximum alignment of its
fields.
Darksonn marked this conversation as resolved.
Show resolved Hide resolved

Formally, the first guarantee means that the offset of any field in the struct
is divisible by that field's alignment. 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 field are specified in the
Darksonn marked this conversation as resolved.
Show resolved Hide resolved
declaration of the struct.
Copy link
Contributor

Choose a reason for hiding this comment

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

(also can be ignored)

If non-normative statements that provide motivation/context are permitted, it would also be worth noting here that only the compiler has enough information to optimally lay out a generic type for all possible type substitutions. i.e. repr(C) gets you consistency and control at the cost of sometimes not being able to always put generic fields in the best place.


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.

Darksonn marked this conversation as resolved.
Show resolved Hide resolved
There are no other guarantees of data layout made by this representation.

### The `C` Representation

Expand Down