Skip to content

Enum size includes sizes of variants that can't be created #69028

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
WaffleLapkin opened this issue Feb 10, 2020 · 1 comment
Closed

Enum size includes sizes of variants that can't be created #69028

WaffleLapkin opened this issue Feb 10, 2020 · 1 comment
Labels
A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@WaffleLapkin
Copy link
Member

I tried this code:

enum MyPhantomData<T> {
    Always,
    Never(T, core::convert::Infallible),
}

#[test]
fn size() {
    assert_eq!(core::mem::size_of::<MyPhantomData<i32>>(), 0); // Err 8 != 0
}

I expected size test to pass because there is only one value of type MyPhantomData<i32> (MyPhantomData::Always). However, it fails because the actual size of MyPhantomData<i32> is 8. It's also notable that MyPhantomData<()> is actually ZST.

This concrete example may seem strange, but this could also appear in generic code like that:

enum MaybeArrayAndT<T> {
    Nothing,
    ArrayAndT(T, [u8; 1024]),
}

fn main() {
    assert_eq!(size_of::<MaybeArrayAndT<Infallible>>(), 0); // Err: 1025 != 0
}

I'm wondering if there are already issues like that? I couldn't find any...

Meta

Rust playground (stable 1.41.0/nightly 2020-02-09 71c7e149e42cb0fc78a8)

@WaffleLapkin WaffleLapkin added the C-bug Category: This is a bug. label Feb 10, 2020
@jonas-schievink jonas-schievink added A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed C-bug Category: This is a bug. labels Feb 10, 2020
@hanna-kruppe
Copy link
Contributor

Relevant discussion is unfortunately spread over many issues (e.g. rust-lang/unsafe-code-guidelines#79, #49298, #58374, rust-lang/unsafe-code-guidelines#216, and possibly more). I'll close this as a duplicate of #58374 to avoid even more fragmentation.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants