digest: add newtype macros

[newpavlov]

Closes #1069

TODO:

• Add newtype macro for variable hashes
• Add tests for all newtype macros

[baloo]

I'm a bit worried we have to list all the traits in the invocation of the macro and that consumers will drift inconsistent over time.

We can't centrally add/implement a trait (like we could with the CoreWrapper or my set of macros (#1775)).

[newpavlov]

What do you mean by "drift"? The list of traits should not change across semver-compatible releases of digest.

To make the list of traits less annoying, I plan to add several templates for the most common cases. In other words, instead of:

newtype!(
    /// SHA-256 hash
    Sha256(..);
    delegate:
        Debug AlgorithmName
        Clone Default Reset
        BlockSizeUser OutputSizeUser HashMarker
        Update FixedOutput FixedOutputReset
);

We will write:

newtype!(
    /// SHA-256 hash
    Sha256(..);
    delegate_template: FixedOutputHash
);

[baloo]

We've added traits in the previous cycle: #1098 (released in digest 0.10.4)

We may continue to do so in the next one. Having to list the traits means we have to each consumers and bump the list everywhere and release them.
It's less of a problem with a template though.

[tarcieri]

@newpavlov can we get this wrapped up?

[newpavlov]

@tarcieri
I plan to do it in the near future. Unfortunately, I failed to make the macro generic enough, so I probably will just introduce separate macros for fixed, variable, and XOF hashes. Less conventional hashes (e.g. Skein) would have to either rely on type aliases, or introduce their own newtype macros.

[baloo]

How do we deal with hmac::EagerHash?

https://github.com/RustCrypto/MACs/blob/cf736659b45d82dc3d95e6240030a3326381ec96/hmac/src/optim.rs#L27
(RustCrypto/MACs#185)

[baloo]

About MACs, I believe you mentioned you wanted to introduce a similar macro. Could this be done in a followup? Just so we can get back to a usable master.

[newpavlov]

I do not understand why existence of this PR makes master "unusable".

[baloo]

[package]
name = "foobar"
version = "0.1.0"
edition = "2024"

[dependencies]
p256 = "=0.14.0-pre.2"

[patch.crates-io]
digest         = { git = "https://github.com/RustCrypto/traits.git" }
elliptic-curve = { git = "https://github.com/RustCrypto/traits.git" }
signature      = { git = "https://github.com/RustCrypto/traits.git" }

ecdsa   = { git = "https://github.com/RustCrypto/signatures.git" }
rfc6979 = { git = "https://github.com/RustCrypto/signatures.git" }

p256       = { git = "https://github.com/RustCrypto/elliptic-curves.git" }

sha2 = { git = "https://github.com/RustCrypto/hashes.git" }

Unless I miss something, #1810 merged too early and should have been included here (and this PR should fix master and I'd love to have it land as early as possible)

Error output

error[E0432]: unresolved import `digest::impl_oid_carrier`
  --> $HOME/.cargo/git/checkouts/hashes-1d556dee1f65bd53/50ea2ee/sha2/src/lib.rs:28:5
   |
28 |     impl_oid_carrier,
   |     ^^^^^^^^^^^^^^^^ no `impl_oid_carrier` in the root

error[E0412]: cannot find type `OidSha224` in this scope
  --> $HOME/.cargo/git/checkouts/hashes-1d556dee1f65bd53/50ea2ee/sha2/src/lib.rs:50:73
   |
50 | pub type Sha224 = CoreWrapper<CtVariableCoreWrapper<Sha256VarCore, U28, OidSha224>>;
   |                                                                         ^^^^^^^^^ not found in this scope
   |
help: you might be missing a type parameter
   |
50 | pub type Sha224<OidSha224> = CoreWrapper<CtVariableCoreWrapper<Sha256VarCore, U28, OidSha224>>;
   |                +++++++++++

[newpavlov]

Ah, I see. We indeed shouldn't have merged the PR without this one. One alternative workaround could be to use in your patch sections hash of the commit right before the merge.

[baloo]

yeah but then I don't get the other fixes I'm interested in from master. Anyway, for now I just have a branch that merges both this and master, and I get away with it, but it's not ideal.

[baloo]

(the alternative is to revisit #1784 without it I can't pick particular version of a single crate from traits.git without having duplication in the tree (which breaks the trait system))

[newpavlov]

We also could revert #1810 and move its changes into this PR.

UPD: Unfortunately, it can not be reverted automatically, so we would've to do it manually.

[tarcieri]

It would be good to either do that or get this merged ASAP

[newpavlov]

I will try to finalize the remaining parts during this weekend. If I will not be able to do it for some reason, we can revert #1810.