Odd enum size_of computation with named struct variant

[Valloric]

#![allow(dead_code)]

use std::collections::HashSet;
use std::mem::size_of;

struct InlineData {
  size: u8,
  data: [u32; 13],    
}

enum DataA {
  Inline(InlineData),
  Heap(HashSet<u32>),
}

enum DataB {
  Inline {
    size: u8,
    data: [u32; 13],
  },
  Heap(HashSet<u32>),
}

fn main() {
  assert_eq!(size_of::<DataA>(), size_of::<DataB>());
}

Output:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `64`,
 right: `56`', src/main.rs:25:3

Playground link.

I'd expect DataA and DataB to have the same size. I certainly wouldn't expect a simple refactoring that extracts an inline struct into a named one to increase the size of the enum.

My guess as to what's happening here is that rustc isn't smart enough to put the enum discriminant into the InlineData padding bytes.

cc @jwilm

[kennytm]

I believe this is a special case of #46213.

[nagisa]

That is right @kennytm. Closing.

@Valloric in general, since repr(Rust) ADTs have no specified layouts, there should be no expectations with regards to equivalence between two different (or even two same looking) types.

[Valloric]

@nagisa

in general, since repr(Rust) ADTs have no specified layouts, there should be no expectations with regards to equivalence between two different (or even two same looking) types.

Sure, the layout is unspecified, but users still have expectations that what looks like a simple refactor that extracts an unnamed struct into a named one shouldn't increase the size of an enum.

In other words, this particular case doesn't look like a missed optimization to a user; it just looks like a bug.