Guarantee that some structs are zero sized #163

gnzlbg · 2019-07-08T14:48:08Z

This addresses part of #37, by guaranteeing that structs have zero size if they don't contain any non-zero-sized field.

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

RalfJung · 2019-07-13T09:22:27Z

Why are all these size == 0important enough to list them here, wasting precious space and brain resources for every reader?

RalfJung · 2019-07-13T09:23:53Z

One way we could avoid all of that, at the cost of a bigger commitment, is by saying that repr(Rust) is the same as repr(C) after the compiler did some field reordering. That would save us a lot of text. Maybe we can make it a bit more relaxed to give ourselves some more freedom for future changes?

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

…ment

gnzlbg · 2019-07-13T10:12:10Z

Why are all these size == 0important enough to list them here, wasting precious space and brain resources for every reader?

Please, do suggest a better way to guarantee all these details, that does not have those downsides.

gnzlbg · 2019-07-13T10:15:13Z

is by saying that repr(Rust) is the same as repr(C) after the compiler did some field reordering.

It is unclear to me what the consequences of that are. This should deserve its own issues, where that can be explored. AFAICT we do guarantee that ZSTs in repr(C) structs have zero size, but we also do mention that they can introduce padding. It is unclear to me whether we do currently guarantee that a repr(C) struct containing only ZSTs (of possibly varying alignment) is zero-sized.

In particular, while clang do guarantee that zero-sized fields in C structs have zero size (but maybe add padding), I am not sure whether they give structs containing only ZSTs a size of zero.

gnzlbg · 2019-07-13T10:21:34Z

In particular, while clang do guarantee that zero-sized fields in C structs have zero size (but maybe add padding), I am not sure whether they give structs containing only ZSTs a size of zero.

They do in C (https://gcc.godbolt.org/z/Tcu49v), they don't do it in C++ (https://gcc.godbolt.org/z/tn9Mod), but that difference already exist.

RalfJung · 2019-07-13T10:22:55Z

Please, do suggest a better way to guarantee all these details, that does not have those downsides.

A separate file would be a good start IMO.

gnzlbg · 2019-07-13T10:25:38Z

Shall we then remove all mentions of zero-sized types from all layout files and move them to a separate file?

RalfJung · 2019-07-15T09:05:42Z

Hm, that also seems odd somehow as that one file will talk about enums and structus and unions, right?

Maybe having a clearly separated section on "questions around ZST" in each of these files is better. I am not sure.

gnzlbg · 2019-07-15T09:28:28Z

@RalfJung I agree with you in that we need to find a better solution, but I believe it will be easier to refactor the guarantees after we agree on what those should be first. It might well be that, due to the refactor, we end up guaranteeing a little bit more here and there due to making things more general.

I think that a section on each file is probably necessary to work out all of the details, but we also have a top-level layout document at the beginning of this chapter that is currently empty, where we could try to provide general rules that always apply.

Lokathor · 2019-07-15T16:05:27Z

Two step proposal:

Place an entry for "Zero Sized Type (ZST)" in the Glossary. The definition can be very simple but particularly you want to introduce the acronym to people as part of the glossary entry.
Place the info for how a struct/union/enum ends up being zero sized as a section on the pages for each category of type.

gnzlbg · 2019-07-24T15:45:34Z

It's unclear to me whether there is anything else to do with this PR.

The issue that needs resolving is whether this is something we want to guarantee or not, and it is unclear from the comments whether that is the case. If there is no consensus, we should close this PR and document in the issue that there was no consensus about guaranteeing this.

Trying to coalesce these guarantees for easier consumption somewhere is IMO pointless if the guarantees themselves don't have consensus.

RalfJung · 2019-07-24T15:53:46Z

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

+
+Structs with default layout (`repr(Rust)`), layout with increased alignment
+(`repr(align(N))`), packed layout (`repr(packed(N))`), or C-compatible layout
+(`repr(C)`) are zero-sized, if they contain no fields of non-zero size. That is,


Is this an "if and only if"?

I think so. If a struct contains a field of non-zero size, I don't see how it could end up being zero-sized.

I can't think of a counter-example, but it seems like only one direction is much commonly thought about and discussed, so I'd be a bit scared to commit to the other direction as well. Besides, it's usually more important to know when something definitely is a ZST (e.g., so you can ignore it for layout related questions), not when something definitely isn't a ZST.

Fair, but but then we should try to word this in a way that it is clear that only one direction is defined. In particular with the way that conditional and conclusion are reversed here, I think it is easy to interpret this as bidirectional.

English is such a bad language for precise specifications...

So, to make a concrete proposal (also removing a pointless double-negation):

If all fields of a struct have size 0, then the struct has size 0.

Your sentence lists a few representations explicitly, but is there any repr for which this does not make sense?

Well, that statement is trivially true if there struct has no fields. C++ allows structs with no fields but gives them a size of 1, and in theory there could be some kind of #[repr(C++)] that accounts for this.

I'm not sure how plausible #[repr(C++)] is, but another hypothetical use case could be to fix the ABI issue with passing small C++ classes by value.

but is there any repr for which this does not make sense?

If we ever add a repr() for which this does not make sense, then this wouldn't hold for repr(transparent) either.

The current wording mentions all reprs that currently exist, except for repr(transparent) , for which this just follows from its rules.

If you really want to list the repr, I'd propose prepending something like:

For repr(Rust), repr(packed(N)), repr(align(N)) and repr(C):

(Btw, why is it packed but not aligned? Seems inconsistent...)

I've reworded the guarantee with this feedback. Let me know if its ok now.

RalfJung

This looks good to me (other than the nit), but I'd prefer if some other WG member also r+'d.

hanna-kruppe · 2019-07-24T16:04:25Z

r=me as well modulo resolving Ralf's nit (one way or another), this was completely uncontroversial (unlike e.g., enums) and is clearly useful.

RalfJung · 2019-07-26T08:31:17Z

Thanks! This sounds a bit clumsy, which I realize is my fault. But I think at least the meaning is clear. We can always improve the wording later.

gnzlbg added 2 commits July 8, 2019 16:47

Guarantee that some structs are zero sized

4ba0917

Add example

6e4d2c3

RalfJung reviewed Jul 13, 2019

View reviewed changes

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

RalfJung reviewed Jul 13, 2019

View reviewed changes

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

Extend the guarantee to types with default layout but increased align…

c847771

…ment

Extend the guarantee to all struct types

0daf227

RalfJung reviewed Jul 24, 2019

View reviewed changes

RalfJung approved these changes Jul 24, 2019

View reviewed changes

Reword guarantee

ac0cc9c

RalfJung merged commit ea3dbdf into rust-lang:master Jul 26, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Guarantee that some structs are zero sized #163

Guarantee that some structs are zero sized #163

gnzlbg commented Jul 8, 2019

RalfJung commented Jul 13, 2019

RalfJung commented Jul 13, 2019

gnzlbg commented Jul 13, 2019

gnzlbg commented Jul 13, 2019 •

edited

Loading

gnzlbg commented Jul 13, 2019

RalfJung commented Jul 13, 2019

gnzlbg commented Jul 13, 2019

RalfJung commented Jul 15, 2019

gnzlbg commented Jul 15, 2019

Lokathor commented Jul 15, 2019 •

edited

Loading

gnzlbg commented Jul 24, 2019

RalfJung Jul 24, 2019

gnzlbg Jul 24, 2019

hanna-kruppe Jul 24, 2019

RalfJung Jul 24, 2019

RalfJung Jul 25, 2019

comex Jul 26, 2019 •

edited

Loading

gnzlbg Jul 26, 2019

RalfJung Jul 26, 2019

gnzlbg Jul 26, 2019

RalfJung left a comment

hanna-kruppe commented Jul 24, 2019

RalfJung commented Jul 26, 2019

Guarantee that some structs are zero sized #163

Guarantee that some structs are zero sized #163

Conversation

gnzlbg commented Jul 8, 2019

RalfJung commented Jul 13, 2019

RalfJung commented Jul 13, 2019

gnzlbg commented Jul 13, 2019

gnzlbg commented Jul 13, 2019 • edited Loading

gnzlbg commented Jul 13, 2019

RalfJung commented Jul 13, 2019

gnzlbg commented Jul 13, 2019

RalfJung commented Jul 15, 2019

gnzlbg commented Jul 15, 2019

Lokathor commented Jul 15, 2019 • edited Loading

gnzlbg commented Jul 24, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

comex Jul 26, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung left a comment

Choose a reason for hiding this comment

hanna-kruppe commented Jul 24, 2019

RalfJung commented Jul 26, 2019

gnzlbg commented Jul 13, 2019 •

edited

Loading

Lokathor commented Jul 15, 2019 •

edited

Loading

comex Jul 26, 2019 •

edited

Loading