Skip to content

Guarantee the layout of structs with a single non-zero-sized field #164

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

Merged
merged 9 commits into from
Aug 27, 2019
Merged

Guarantee the layout of structs with a single non-zero-sized field #164

Changes from 4 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
3056194
Add examples
gnzlbg Jul 8, 2019
e6a2db1
Use 1-ZST terminology
gnzlbg Aug 15, 2019
8df48e4
Reword
gnzlbg Aug 16, 2019
bd8e2fe
1-ZST fields are ignored
gnzlbg Aug 16, 2019
eae3f3c
Struct with no fields
gnzlbg Aug 16, 2019
4442b41
Add note to ZST struct section
gnzlbg Aug 16, 2019
51f0ec0
Remove unnecessary section
gnzlbg Aug 16, 2019
1883271
rearrange a bit and be more explicit about how our rules interact
RalfJung Aug 17, 2019
054361b
Merge pull request #2 from RalfJung/single_field_struct
gnzlbg Aug 17, 2019
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
27 changes: 18 additions & 9 deletions reference/src/layout/structs-and-tuples.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -141,6 +141,22 @@ struct Zst2(Zst1, Zst0);
# }
```

#### Structs with 1-ZST fields

For the purposes of struct layout [1-ZST] fields are ignored.

For example,

```rust
type Zst1 = ();
struct S1(i32, Zst1);

type Zst2 = [u16; 0];
struct S2(Zst2, Zst1);
```

the layout of `S1` is the same as that of `i32` and the layout of `S2` as that of `Zst2`.
Copy link
Member

Choose a reason for hiding this comment

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

This is saying more than just "1-ZST fields are ignored".

You are also assuming here that single-field structs have layout identical to their only field. That is a separate statement, and should IMO get a separate section.

Copy link
Member

Choose a reason for hiding this comment

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

(This comment is still open.)


#### Unresolved questions

During the course of the discussion in [#11] and [#12], various
Expand All @@ -150,15 +166,6 @@ issue has been opened for further discussion on the repository. This
section documents the questions and gives a few light details, but the
reader is referred to the issues for further discussion.

**Single-field structs ([#34]).** If you have a struct with single field
(`struct Foo { x: T }`), should we guarantee that the memory layout of
`Foo` is identical to the memory layout of `T` (note that ABI details
around function calls may still draw a distinction, which is why
`#[repr(transparent)]` is needed). What about zero-sized types like
`PhantomData`?

[#34]: https://github.com/rust-rfcs/unsafe-code-guidelines/issues/34

**Homogeneous structs ([#36]).** If you have homogeneous structs, where all
the `N` fields are of a single type `T`, can we guarantee a mapping to
the memory layout of `[T; N]`? How do we map between the field names
Expand Down Expand Up @@ -400,3 +407,5 @@ proposal (and -- further -- it does not match our existing behavior):
thread](https://github.com/rust-rfcs/unsafe-code-guidelines/pull/31#discussion_r224955817)).
- Many people would prefer the name ordering to be chosen for
"readability" and not optimal layout.

[1-ZST]: ../glossary.md#zero-sized-type--zst