Guarantee repr(C) enum discriminants are stable within a compilation #1454
Conversation
…within a compilation
joshlf
changed the title
|
Friendly ping 🙂 |
1 similar comment
|
Friendly ping 🙂 |
|
Is there some context for this change? Has it been discussed by the lang team? |
| > discriminants will have the same size and alignment *within a given | ||
| > compilation of the program.* This is true for both field-less enums and | ||
| > for enums with fields. |
There was a problem hiding this comment.
"within a given compilation of the program" doesn't seem clear to me what that means. Certainly all types have the same size and alignment during compilation. I'm not sure I can guess what this is trying to say, can you clarify?
There was a problem hiding this comment.
Maybe I should phrase this differently. The idea is that, whatever choice rustc makes about the size and alignment of the discriminant of a repr(C) enum, it makes the same choice for all repr(C) enums within a program.
The reason this is important is that the size and alignment aren't guaranteed in any way other than to say "rustc will choose some size and alignment." This puts unsafe code in a bind: how do you know what the size and alignment of the discriminant is if you're trying to work with the layout of an enum type? With this added text, you can construct a "dummy" field-less repr(C) enum, query for its size and alignment using size_of and align_of, and take these to be equal to the size and alignment of the discriminant of the enum you're working with.
The specific context is that zerocopy's TryFromBytes trait can currently be derived on field-less enums, and we want to add support for data-ful enums, but we can't without this guarantee (or some other way of querying for the size and alignment of repr(C) enum discriminants).
There was a problem hiding this comment.
@joshlf: We discussed this in the rustdocs call today. This is going to need to be lang nominated, but before we do that, we'd like this language to be as clear as possible. Do you want to take another pass at stating this more clearly as discussed?
No, but I figured it'd be pretty uncontroversial. Happy to CC them here if you'd like. |
|
@joshlf: Before we lang nominate it, could you update the PR description with a summary of the change being proposed here and describe in some detail the motivations for this change. E.g., if you could go into more detail about the situation you have with the If you have any ideas for how we would actually encode this as a test in our test suite, that would be good to detail also. |
| > However, it is guaranteed that, for any two `repr(C)` enum types, their | ||
| > discriminants will have the same size and alignment *within a given | ||
| > compilation of the program.* This is true for both field-less enums and | ||
| > for enums with fields. |
There was a problem hiding this comment.
You probably mean the tag, not the discriminant. The discriminant is the value you get when you cast an enum to an integer or call std::mem::discriminant on it. The tag is the actual representation in memory. It may be smaller or larger than the discriminant. Without repr(C) or repr(iN) the tag may be a different integer than the discriminant or the discriminant may be represented using niches instead.
ehuss
added
the
S-waiting-on-author
No description provided.