Differing results for std::mem::size_of computation

[feds01]

I have a project that is split into two repositories:

• https://github.com/hash-org/hashc (hashc)
• https://github.com/hash-org/hi (hi)

The hi repository specifies through cargo to be dependent on the master branch of hashc.

hashc repository crates contain some static_assert_size! assertions, which are implemented in the following way (exactly as it is in rustc itself):

pub macro static_assert_size($ty:ty, $size:expr) {
    const _: [(); $size] = [(); ::std::mem::size_of::<$ty>()];
}

Building hashc on its own with the following assertions in place does not produce an error:

#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]
mod size_asserts {
    use hash_utils::assert::static_assert_size;

    use super::*;

    static_assert_size!(Statement, 64);
    static_assert_size!(Terminator, 104);
    static_assert_size!(RValue, 40);
}

However, building hi repository trips one of the assertions as having a mismatching size:

error[E0308]: mismatched types
    --> /Users/alex/.cargo/git/checkouts/hashc-3190687590a997bc/556827f/compiler/hash-utils/src/assert.rs:6:28
     |
5    | pub macro static_assert_size($ty:ty, $size:expr) {
     | ---------------------------- in this expansion of `static_assert_size!`
6    |     const _: [(); $size] = [(); ::std::mem::size_of::<$ty>()];
     |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected an array with a fixed size of 104 elements, found one with 96 elements
     |
    ::: /Users/alex/.cargo/git/checkouts/hashc-3190687590a997bc/556827f/compiler/hash-ir/src/ir.rs:1534:37
     |
1534 |     static_assert_size!(Terminator, 104);
     |     ------------------------------------
     |     |                               |
     |     |                               help: consider specifying the actual array length: `96`
     |     in this macro invocation

It is bizarre that this is happening on the same machine with the same toolchain, but the crates are being required through a repository rather than a local crate.

rustc --version --verbose:

rustc 1.73.0-nightly (6ef7d16be 2023-08-19)
binary: rustc
commit-hash: 6ef7d16be0fb9d6ecf300c27990f4bff49d22d46
commit-date: 2023-08-19
host: x86_64-apple-darwin
release: 1.73.0-nightly
LLVM version: 17.0.0

[feds01]

My apologies, after a more detailed investigation this seems as if it is an issue with updating project dependencies. One of the project dependencies smallvec is specified by the hashc lockfile to be at 1.10.0, but running cargo update bumps smallvec to 1.11.0 which introduces the breaking change. Should this be closed, or perhaps moved to cargo repository?

[Noratrieb]

Doesn't look like a bug to me then, just a confusing consequence of checking in library lockfiles. One thing is that emitting hard errors in size asserts is a pretty bad thing in general to do as changes in the layout algorithm (or as we've seen here, in dependencies) could cause build failures. They should be #[test]s instead (rustc is special here because it controls the layout algorithm :D).
Thanks for the report anyways!