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.

E.g.

#[derive(Hash)] enum SomeEnum { One, Two, Three, }

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