Ask questionsBreaking change/regression in nightly? Hash of `Discriminant` now produces different results across CPU architectures

Hi, we just noticed that there has been changes to the inner of Discriminant, i.e. DiscriminantKind, that causes a Hash of a discriminant to produce different results across CPU architectures.


enum SomeEnum {

When hashing this in the current stable one gets writes that look like this:

Hash for One:
[0, 0, 0, 0, 0, 0, 0, 0]

Hash for Two
[1, 0, 0, 0, 0, 0, 0, 0]

Hash for Tree
[2, 0, 0, 0, 0, 0, 0, 0]

And depending on the architecture in the current nightly one gets for armv7-unknown-linux-gnueabihf:

Hash for One:
[0, 0, 0, 0]

Hash for Two
[1, 0, 0, 0]

Hash for Tree
[2, 0, 0, 0,]

However for ex x86_64-unknown-linux-gnu it is still 8 bytes as before.

This is a problem as e.g. CRC hashes are no longer compatible between CPU architectures. Not sure if this was intended, but it seems like a breaking change to me?

In our case we are sending structures between an embedded thumbv7em-none-eabihf and an armv7-unknown-linux-gnueabihf system where CRCs are calculated based on #[derive(Hash)] for said structures to be sent.

rustc --version --verbose:

rustc 1.46.0-nightly (5db778aff 2020-07-09)
binary: rustc
commit-hash: 5db778affee7c6600c8e7a177c48282dab3f6292
commit-date: 2020-07-09
host: x86_64-unknown-linux-gnu
release: 1.46.0-nightly
LLVM version: 10.0

rustc 1.44.1 (c7087fe00 2020-06-17)
binary: rustc
commit-hash: c7087fe00d2ba919df1d813c040a5d47e43b0fe7
commit-date: 2020-06-17
host: x86_64-unknown-linux-gnu
release: 1.44.1
LLVM version: 9.0

Answer questions scottmcm

I see lang was pinged here, but it's not clear to me that this is a lang issue. AFAIK Discriminant<> and Hash are libs's domain.

(Personally it seems like there's no guarantee that Hash does the same thing on different platforms, so I'd be inclined to solve this by just putting a note in the docs that Hashes across different builds can be different. I do like the point that it seems weird to a discriminant to be a [ui]size type instead of a [ui]N type, though.)


Related questions

Spurious NaNs produced by trig functions with valid inputs on Windows GNU toolchains hot 3
using 'cargo install xsv' on windows 10 triggers rustc internal error hot 2
under latest MinGW, cannot link with C code using stdout hot 2
Archive all nightlies hot 2
chain() make collect very slow hot 1
if/while Some(n) = &mut foo sugar will leak a temporary mutable borrow to current scope in particular situation hot 1
build an empty project failed (undefined reference to `__onexitbegin') hot 1
Invalid collision with TryFrom implementation? hot 1
Crater runs for Rust 1.38.0 hot 1
Spurious NaNs produced by trig functions with valid inputs on Windows GNU toolchains hot 1
Building LLVM with Clang fails hot 1
Internal compiler error: can't buffer lints after HIR lowering hot 1
E0373 help suggests `move async` but the correct syntax is `async move` hot 1
Tracking issue for `Option::contains` and `Result::contains` hot 1
async fn + rustfmt don't "just work" inside of RLS hot 1
Github User Rank List