@@ -122,7 +122,6 @@ compiler will not reorder it, to allow for the possibility of
122122unsizing. E.g., ` struct Foo { x: u16, y: u32 } ` and `struct Foo<T > {
123123x: u16, y: T }` where ` T = u32` are not guaranteed to be identical.
124124
125- <<<<<<< HEAD
126125#### Zero-sized structs
127126
128127For ` repr(Rust) ` , ` repr(packed(N)) ` , ` repr(align(N)) ` , and ` repr(C) `
@@ -142,11 +141,10 @@ struct Zst2(Zst1, Zst0);
142141# }
143142```
144143
145- =======
146144#### Default layout of structs with a single non-zero-sized field
147145
148146The default layout of structs with a single non-zero-sized field is the same as
149- the layout of that field if the alignment requirement of all other fields is 1.
147+ the layout of that field if all other fields are [ 1-ZST ]
150148
151149For example, the layout of:
152150
@@ -160,9 +158,7 @@ is the same as the layout of `i32`, but the layout of:
160158#[repr(align(16))] struct Zst ;
161159struct SomeOtherStruct (i32 , Zst );
162160```
163-
164- is ** unspecified** , since there is a zero-sized field in ` SomeOtherStruct ` with
165- alignment greater than 1.
161+ is ** unspecified** , since ` Zst ` is not a [ 1-ZST] .
166162
167163#### Unresolved questions
168164
@@ -423,3 +419,5 @@ proposal (and -- further -- it does not match our existing behavior):
423419 thread] ( https://github.com/rust-rfcs/unsafe-code-guidelines/pull/31#discussion_r224955817 ) ).
424420- Many people would prefer the name ordering to be chosen for
425421 "readability" and not optimal layout.
422+
423+ [ 1-ZST ] : ../glossary.md#zero-sized-type--zst
0 commit comments