diff options
| author | Peter Todd <pete@petertodd.org> | 2018-12-07 19:54:16 -0500 |
|---|---|---|
| committer | Emilio Cobos Álvarez <emilio@crisal.io> | 2018-12-16 20:36:25 +0100 |
| commit | d84bdba72888a42a67c1771b0a62f8517c8964cb (patch) | |
| tree | 54c21cb914fb46e77324de1c7f8ce4247e1accc4 /src/test/rustdoc/mod-stackoverflow.rs | |
| parent | fba23d01d16db8b83b2415bc538d2a850fcf24da (diff) | |
| download | rust-d84bdba72888a42a67c1771b0a62f8517c8964cb.tar.gz rust-d84bdba72888a42a67c1771b0a62f8517c8964cb.zip | |
Add test to check order of repr(int) enum fields
RFC #2195 specifies that a repr(int) enum such as:
#[repr(u8)]
enum MyEnum {
B { x: u8, y: i16, z: u8 },
}
has a layout that is equivalent to:
#[repr(C)]
enum MyEnumVariantB { tag: u8, x: u8, y: i16, z: u8 },
However this isn't actually implemented, with the actual layout being
roughly equivalent to:
union MyEnumPayload {
B { x: u8, y: i16, z: u8 },
}
#[repr(packed)]
struct MyEnum {
tag: u8,
payload: MyEnumPayload,
}
Thus the variant payload is *not* subject to repr(C) ordering rules, and
gets re-ordered as `{ x: u8, z: u8, z: i16 }`
The existing tests added in pull-req #45688 fail to catch this as the
repr(C) ordering just happens to match the current Rust ordering in this
case; adding a third field reveals the problem.
Diffstat (limited to 'src/test/rustdoc/mod-stackoverflow.rs')
0 files changed, 0 insertions, 0 deletions
