[derive] Implement a IntoBytes-based Hash derive

[max-heller]

The standard library's derive for Hash generates a recursive descent into the fields of the type it is applied to. This commit adds an alternative derive that generates an optimized, byte-oriented Hash implementation for types that implement IntoBytes. Instead of a recursive descent, the generated implementation makes a single call to Hasher::write() in both Hash::hash() and Hash::hash_slice(), feeding the hasher the bytes of the type or slice all at once.

Resolves #2075

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.42%. Comparing base (2c8ef74) to head (05f4718).
Report is 1 commits behind head on v0.8.x.

Additional details and impacted files

@@           Coverage Diff           @@
##           v0.8.x    #2159   +/-   ##
=======================================
  Coverage   87.42%   87.42%           
=======================================
  Files          16       16           
  Lines        6115     6115           
=======================================
  Hits         5346     5346           
  Misses        769      769           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jswrenn]

Thank you for the contribution! I'm in awe you managed to pass our CI on your first commit! At a glance, this looks great; I'll give a more thorough review tomorrow.

I think the right choice is to advocate for the usage pattern of derive(zerocopy::Hash), and thus preserve the property that derive(Trait) derives Trait. However, we need to be mindful that this could conflict with other imports of core::hash::Hash if the user writes use zerocopy_derive::*.

The Hash macro (but not trait) is in the prelude. Would a subsequent glob import from zerocopy_derive overwrite it?

[jswrenn]

Unfortunately, this can lead to errors. This code, for example:

use zerocopy::*;

#[derive(Hash)]
struct Foo;

...produces this error:

error[E0659]: `Hash` is ambiguous
   --> examples/foo.rs:3:10
    |
3   | #[derive(Hash)]
    |          ^^^^ ambiguous name
    |
    = note: ambiguous because of a conflict between a name from a glob import and an outer scope during import or macro resolution
note: `Hash` could refer to the derive macro imported here
   --> examples/foo.rs:1:5
    |
1   | use zerocopy::*;
    |     ^^^^^^^^^^^
    = help: consider adding an explicit import of `Hash` to disambiguate
    = help: or use `crate::Hash` to refer to this derive macro unambiguously
note: `Hash` could also refer to the derive macro defined here
   --> /home/ubuntu/.rustup/toolchains/nightly-2024-11-06-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/prelude/mod.rs:151:13
    |
151 |     pub use super::v1::*;

Unfortunately, we encourage users to glob-import from zerocopy_derive. Given this, we should probably follow bytemuck's lead and call it something like ByteHash.

[max-heller]

Unfortunately, this can lead to errors. This code, for example:

use zerocopy::*;

#[derive(Hash)]
struct Foo;

...produces this error:

error[E0659]: `Hash` is ambiguous
   --> examples/foo.rs:3:10
    |
3   | #[derive(Hash)]
    |          ^^^^ ambiguous name
    |
    = note: ambiguous because of a conflict between a name from a glob import and an outer scope during import or macro resolution
note: `Hash` could refer to the derive macro imported here
   --> examples/foo.rs:1:5
    |
1   | use zerocopy::*;
    |     ^^^^^^^^^^^
    = help: consider adding an explicit import of `Hash` to disambiguate
    = help: or use `crate::Hash` to refer to this derive macro unambiguously
note: `Hash` could also refer to the derive macro defined here
   --> /home/ubuntu/.rustup/toolchains/nightly-2024-11-06-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/prelude/mod.rs:151:13
    |
151 |     pub use super::v1::*;

Unfortunately, we encourage users to glob-import from zerocopy_derive. Given this, we should probably follow bytemuck's lead and call it something like ByteHash.

That's unfortunate, I do like to preserve derive(Trait) -> impl Trait as you mentioned. I renamed it to ByteHash to be consistent with bytemuck. I could also see a case for HashBytes, I'm not sure if there's much other precedent for naming these specialized derives.

[jswrenn]

One last (I think) nit: Could you leave a comment why deferring to impl_block isn't appropriate here?

[max-heller]

Done!

[jswrenn]

This looks great to me! Thank you for the contribution!