bjoernager/rust
bjoernager/rust
1
Fork 0
Code Activity

Auto merge of #96846 - matthiaskrgr:rollup-yxu9ot9, r=matthiaskrgr

Browse source 
Rollup of 5 pull requests

Successful merges:

 - #96617 (Fix incorrect syntax suggestion with `pub async fn`)
 - #96828 (Further elaborate the lack of guarantees from `Hasher`)
 - #96829 (Fix the `x.py clippy` command)
 - #96830 (Add and tweak const-generics tests)
 - #96835 (Add more eslint rules)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
This commit is contained in:
bors 2022-05-08 21:37:26 +00:00
commit cb12198715
9 changed files with 148 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

23
library/core/src/hash/mod.rs
View file

@ -268,10 +268,29 @@ pub use macros::Hash;
/// instance (with [`write`] and [`write_u8`] etc.). Most of the time, `Hasher`
/// instances are used in conjunction with the [`Hash`] trait.
///
/// This trait makes no assumptions about how the various `write_*` methods are
/// This trait provides no guarantees about how the various `write_*` methods are
/// defined and implementations of [`Hash`] should not assume that they work one
/// way or another. You cannot assume, for example, that a [`write_u32`] call is
/// equivalent to four calls of [`write_u8`].
/// equivalent to four calls of [`write_u8`]. Nor can you assume that adjacent
/// `write` calls are merged, so it's possible, for example, that
/// ```
/// # fn foo(hasher: &mut impl std::hash::Hasher) {
/// hasher.write(&[1, 2]);
/// hasher.write(&[3, 4, 5, 6]);
/// # }
/// ```
/// and
/// ```
/// # fn foo(hasher: &mut impl std::hash::Hasher) {
/// hasher.write(&[1, 2, 3, 4]);
/// hasher.write(&[5, 6]);
/// # }
/// ```
/// end up producing different hashes.
///
/// Thus to produce the same hash value, [`Hash`] implementations must ensure
/// for equivalent items that exactly the same sequence of calls is made -- the
/// same methods with the same parameters in the same order.
///
/// # Examples
///