about summary refs log tree commit diff
path: root/src/test/rustdoc/mod-stackoverflow.rs
diff options
context:
space:
mode:
authorPeter Todd <pete@petertodd.org>2018-12-07 19:54:16 -0500
committerEmilio Cobos Álvarez <emilio@crisal.io>2018-12-16 20:36:25 +0100
commitd84bdba72888a42a67c1771b0a62f8517c8964cb (patch)
tree54c21cb914fb46e77324de1c7f8ce4247e1accc4 /src/test/rustdoc/mod-stackoverflow.rs
parentfba23d01d16db8b83b2415bc538d2a850fcf24da (diff)
downloadrust-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