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

gnzlbg · 2019-07-08T14:58:40Z

This PR guarantees the layout of structs with a single non-zero-sized field to be the same layout as that of that field if the alignment requirements of all other fields is 1.

Closes #34 .

reference/src/layout/structs-and-tuples.md

Lokathor · 2019-07-13T16:16:42Z

Can we make this guarantee stronger? It seems like as long as all ZST values have an alignment less than or equal to the Non-ZST value that layout should be unaffected.

eg: *mut T and *mut T, PhantomData<&mut T> should fairly probably be definitely the same.

hanna-kruppe · 2019-07-13T17:57:20Z

PhantomData<T> has alignment 1 regardless of T so it's already covered.

gnzlbg · 2019-07-24T15:30:15Z

Can we make this guarantee stronger?

We could. This was not discussed in the issue, but I suppose that we can make it stronger as a follow up.

gnzlbg · 2019-07-24T16:23:23Z

@rkruppe @RalfJung what do you think about strengthening the guarantee to:

The default layout of structs with a single non-zero-sized field is the same as
the layout of that field if the alignment requirement of all other fields is less than or equal to
the alignment requirement of the non-zero-sized field.

?

hanna-kruppe · 2019-07-24T16:29:24Z

I don't think we should innovate here (has this wording ever popped up anywhere before?), especially as @Lokathor's motivation for proposing it (PhantomData) doesn't need this stronger guarantee after all. The only additional things this strengthening covers are empty arrays and user-declared ZSTs with an explicit repr(align(N)) neither of which seems important to me. It also deviates from the precedent set by repr(transparent) -- in a sense we're doing this to downgrade repr(transparent) from a very important opt-in to a guardrail and arguably shouldn't go further.

RalfJung · 2019-07-26T18:36:48Z

Unblocking as the 1-ZST PR landed. Or was this blocked on something else?

gnzlbg · 2019-08-15T06:42:42Z

So I've updated this to use the "1-ZST" terminology and noticed two things:

the text is a bit harder to read (maybe there is a better way to use the "1-ZST" terminology?) - I also noticed this in Guarantee the layout of some unions having a single non-zero-sized field #161 .
we could guarantee the layout of

struct S([0; u8], [0; u8], [0; u16]);

to be the same as that of [0; u 16] by, instead of guaranteeing this for structs with one non-zero-sized field, guaranteeing those for structs that have one field that is not a 1-ZST.

I am not sure whether that is worth doing, and tend to agree with @rkruppe that the simple guarantee is enough. Just food for thought. What isn't clear to me is how we could generalize such a guarantee in the spirit of what @Lokathor proposed here, but without mentioning that one type is a non-zero-sized type.

RalfJung · 2019-08-16T15:26:19Z

structs that have one field that is not a 1-ZST.

I think this is what we should do. It is most consistent. The current definition leaves a weird "gap".

reference/src/layout/structs-and-tuples.md

RalfJung · 2019-08-16T15:31:53Z

the text is a bit harder to read (maybe there is a better way to use the "1-ZST" terminology?) - I also noticed this in #161 .

I think this might be due to the mismatch mentioned/"gap" in my previous post. Or do you think this is hard to read?

"The default layout of structs where only a single field is not a 1-ZST, is the same as the layout of said field".

gnzlbg · 2019-08-16T15:36:59Z

Done.

reference/src/layout/structs-and-tuples.md

RalfJung · 2019-08-16T16:40:27Z

In fact, I personally would just go for the stronger statement that for struct layout, 1-ZST are ignored. I don't see any reason to guarantee/propose some instances of that without guaranteeing/proposing the general, simpler to explain and more useful, principle.

Both the current content of this PR and "structs consisting only of 1-ZST are 1-ZST" then basically just fall out of that principle, and the additional orthogonal statemenets

structs with no fields (and no repr annotation) are 1-ZST
structs with 1 field (and no repr annotation) have the same layout as that field

RalfJung · 2019-08-16T17:44:25Z

reference/src/layout/structs-and-tuples.md

+struct S2(Zst2, Zst1);
+```
+
+the layout of `S1` is the same as that of `i32` and the layout of `S2` as that of `Zst2`. 


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.

(This comment is still open.)

hanna-kruppe · 2019-08-16T17:46:26Z

"1-ZST fields are ignored for layout" seems to go beyond what got consensus back when struct layout was discussed. For example, I think it would mean that all instantiations of this type (i.e., regardless of the unit) have the same layout:

struct Vec2<Unit> {
    x: f32,
    y: f32,
    _unit: PhantomData<Unit>
}

but as was discussed extensively, there is some desire to keep open the possibilities of randomized and profile-driven type layout decision, and none of the very small restrictions on that (single-field structs, single-variant enums, etc.) that were proposed without anyone objecting cover this.

Don't get me wrong, I am personally also very much in favor of layout ignoring 1-ZSTs universally (and many other things besides). But I don't think we should just "sneak in" something which was explicitly discussed and didn't get consensus.

Edit: on second thought I'm not so sure anymore, since arguably Vec2<A> and Vec2<B> are still different (types, substs) tuples even if the PhantomData field is ignored? That seems painfully subtle and lawyering-prone, though.

reference/src/layout/structs-and-tuples.md

RalfJung · 2019-08-16T17:48:21Z

For example, I think it would mean that all instantiations of this type (i.e., regardless of the unit) have the same layout:

I don't see how it would say that. Those are still all separate instances of a generic type. The 1-ZST is ignored, but the type parameter is not.

hanna-kruppe · 2019-08-16T17:49:39Z

I realized the same thing after posting and just finished editing it in 😅

RalfJung · 2019-08-16T17:51:08Z

@rkruppe in other words, we don't guarantee that the following two have the same layout:

struct Vec2_1 {
    x: f32,
    y: f32,
}
struct Vec2_2 {
    x: f32,
    y: f32,
}

Likewise, we don't guarantee that all instance of these have the same layout:

struct Vec2Plus<T> {
    x: f32,
    y: f32,
    plus: *mut T,
}

No ZST are involved in any of this. Why would the ZST in your example make any difference?

The fact that Vec2<A> and Vec2<B> don't have to have the same layout is an instance of the same principle. We have nominal typing, and every different choice of parameters is a different "name".

EDIT: Ah, you part-way agree. Well see this post for why we need that lawyering anyway, and the ZST question is entirely orthogonal. ;)

reference/src/layout/structs-and-tuples.md

RalfJung · 2019-08-17T12:56:05Z

Opened a PR for my remaining comments: gnzlbg#2

rearrange a bit and be more explicit about how our rules interact

RalfJung

LGTM!

@rkruppe what do you think?

hanna-kruppe · 2019-08-17T14:27:31Z

I'm perpetually confused by what any given person means by "layout", didn't we at some point agree to stop using that term to prevent confusion? Assuming that in this diff "layout" = size, align, field offsets and padding, possibly niches but definitely not call ABI, the content seems fine. But I'm unsure whether, editorially speaking, we should already be avoiding "layout" in new paragraphs or if that's gonna be a separate clean-up PR that goes over all the documents.

RalfJung · 2019-08-17T14:37:48Z

That would be #153. I think the plan (like in the other PR) was to land this PR with the vague wording so that we have some examples to work with when finalizing the terminology. It's much easier to do that when you have some examples.

gnzlbg · 2019-08-27T14:44:58Z

What we mean by layout here will be precised in #153 .

gnzlbg mentioned this pull request Jul 9, 2019

Is Box FFI-safe? #157

Closed

RalfJung reviewed Jul 13, 2019

View reviewed changes

reference/src/layout/structs-and-tuples.md Outdated Show resolved Hide resolved

RalfJung mentioned this pull request Jul 13, 2019

Guarantee that some structs are zero sized #163

Merged

gnzlbg added the blocked label Jul 24, 2019

This was referenced Jul 24, 2019

Abbreviation for zero-sized types with particular alignment #172

Closed

Clarify Box<T> representation and its use in FFI rust-lang/rust#62514

Merged

gnzlbg mentioned this pull request Jul 25, 2019

#[repr(transparent)] for Box<T>? rust-lang/rust#52976

Closed

RalfJung removed the blocked label Jul 26, 2019

RalfJung added the A-layout Topic: Related to data structure layout (`#[repr]`) label Aug 14, 2019

Add examples

3056194

gnzlbg force-pushed the single_field_struct branch from b0f2ef5 to b281933 Compare August 15, 2019 06:32

gnzlbg mentioned this pull request Aug 15, 2019

Make niches part of layout and expand call ABI #153

Closed

RalfJung reviewed Aug 16, 2019

View reviewed changes

reference/src/layout/structs-and-tuples.md Outdated Show resolved Hide resolved

RalfJung reviewed Aug 16, 2019

View reviewed changes

reference/src/layout/structs-and-tuples.md Outdated Show resolved Hide resolved

Use 1-ZST terminology

e6a2db1

gnzlbg force-pushed the single_field_struct branch from b281933 to e6a2db1 Compare August 16, 2019 15:32

Reword

8df48e4

gnzlbg force-pushed the single_field_struct branch from 008158c to 8df48e4 Compare August 16, 2019 15:36

RalfJung reviewed Aug 16, 2019

View reviewed changes

reference/src/layout/structs-and-tuples.md Outdated Show resolved Hide resolved

RalfJung mentioned this pull request Aug 16, 2019

defining zero-sized structs #37

Open

gnzlbg added 2 commits August 16, 2019 19:20

1-ZST fields are ignored

bd8e2fe

Struct with no fields

eae3f3c

RalfJung reviewed Aug 16, 2019

View reviewed changes

reference/src/layout/structs-and-tuples.md Show resolved Hide resolved

Add note to ZST struct section

4442b41

RalfJung reviewed Aug 16, 2019

View reviewed changes

reference/src/layout/structs-and-tuples.md Outdated Show resolved Hide resolved

gnzlbg and others added 2 commits August 16, 2019 20:21

Remove unnecessary section

51f0ec0

rearrange a bit and be more explicit about how our rules interact

1883271

Merge pull request #2 from RalfJung/single_field_struct

054361b

rearrange a bit and be more explicit about how our rules interact

RalfJung approved these changes Aug 17, 2019

View reviewed changes

gnzlbg merged commit 308c474 into rust-lang:master Aug 27, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

gnzlbg commented Jul 8, 2019 •

edited

Loading

Lokathor commented Jul 13, 2019

hanna-kruppe commented Jul 13, 2019

gnzlbg commented Jul 24, 2019

gnzlbg commented Jul 24, 2019

hanna-kruppe commented Jul 24, 2019

RalfJung commented Jul 26, 2019

gnzlbg commented Aug 15, 2019

RalfJung commented Aug 16, 2019

RalfJung commented Aug 16, 2019

gnzlbg commented Aug 16, 2019

RalfJung commented Aug 16, 2019 •

edited

Loading

RalfJung Aug 16, 2019

RalfJung Aug 16, 2019

hanna-kruppe commented Aug 16, 2019 •

edited

Loading

RalfJung commented Aug 16, 2019

hanna-kruppe commented Aug 16, 2019

RalfJung commented Aug 16, 2019 •

edited

Loading

RalfJung commented Aug 17, 2019

RalfJung left a comment

hanna-kruppe commented Aug 17, 2019

RalfJung commented Aug 17, 2019

gnzlbg commented Aug 27, 2019

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

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

Conversation

gnzlbg commented Jul 8, 2019 • edited Loading

Lokathor commented Jul 13, 2019

hanna-kruppe commented Jul 13, 2019

gnzlbg commented Jul 24, 2019

gnzlbg commented Jul 24, 2019

hanna-kruppe commented Jul 24, 2019

RalfJung commented Jul 26, 2019

gnzlbg commented Aug 15, 2019

RalfJung commented Aug 16, 2019

RalfJung commented Aug 16, 2019

gnzlbg commented Aug 16, 2019

RalfJung commented Aug 16, 2019 • edited Loading

RalfJung Aug 16, 2019

Choose a reason for hiding this comment

RalfJung Aug 16, 2019

Choose a reason for hiding this comment

hanna-kruppe commented Aug 16, 2019 • edited Loading

RalfJung commented Aug 16, 2019

hanna-kruppe commented Aug 16, 2019

RalfJung commented Aug 16, 2019 • edited Loading

RalfJung commented Aug 17, 2019

RalfJung left a comment

Choose a reason for hiding this comment

hanna-kruppe commented Aug 17, 2019

RalfJung commented Aug 17, 2019

gnzlbg commented Aug 27, 2019

gnzlbg commented Jul 8, 2019 •

edited

Loading

RalfJung commented Aug 16, 2019 •

edited

Loading

hanna-kruppe commented Aug 16, 2019 •

edited

Loading

RalfJung commented Aug 16, 2019 •

edited

Loading