Rollup merge of - the8472:hash-portability, r=dtolnay

Document non-guarantees for Hash

Dependence on endianness and type sizes was reported for enum discriminants in  but it is a more general
issue since for example the default implementation of `Hasher::write_usize` uses native endianness.
Additionally the implementations of library types are occasionally changed as their internal fields
change or hashing gets optimized.

## Question

Should this go on the module level documentation instead since it also concerns `Hasher` to some extent and not just `Hash`?

resolves 
This commit is contained in:
Matthias Krüger 2021-11-27 11:46:42 +01:00 committed by GitHub
commit 43279b2749
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -164,6 +164,19 @@ mod sip;
/// `0xFF` byte to the `Hasher` so that the values `("ab", "c")` and `("a",
/// "bc")` hash differently.
///
/// ## Portability
///
/// Due to differences in endianness and type sizes, data fed by `Hash` to a `Hasher`
/// should not be considered portable across platforms. Additionally the data passed by most
/// standard library types should not be considered stable between compiler versions.
///
/// This means tests shouldn't probe hard-coded hash values or data fed to a `Hasher` and
/// instead should check consistency with `Eq`.
///
/// Serialization formats intended to be portable between platforms or compiler versions should
/// either avoid encoding hashes or only rely on `Hash` and `Hasher` implementations that
/// provide additional guarantees.
///
/// [`HashMap`]: ../../std/collections/struct.HashMap.html
/// [`HashSet`]: ../../std/collections/struct.HashSet.html
/// [`hash`]: Hash::hash