-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missed optimization when putting structs with padding an enum #109555
Comments
This is incompatible with the assumption that you can write a value of type |
See also #70230 to define padding such that niches are possible. However, I think that still wouldn't allow |
Today you can use |
I'm going to close this because it's not currently legal to do such an optimization because of the semantics of padding. This would need a language change (like move-only fields, or different padding semantics) to be allowed, but language changes are for IRLO or zulip, not this issue tracker. I'll note that you can get layout optimizations in certain situations by adding a restriction instead of having padding: #[repr(u8)]
enum ZeroByte { Zero = 0 }
struct S {
a: u32,
b: i128,
}
struct S2 {
a: u32,
b: i128,
c: ZeroByte,
}
fn main() {
use std::mem::size_of;
dbg!(size_of::<S>());
dbg!(size_of::<Option<S>>());
dbg!(size_of::<S2>());
dbg!(size_of::<Option<S2>>());
}
|
this code prints
when it could have instead used the free padding bytes in
S
for the discriminant, soFoo
would be the same size asS
The text was updated successfully, but these errors were encountered: