digest: add buffering macros

[newpavlov]

The new macros create buffered wrapper types and replace the old wrapper types (except CtVariableCoreWrapper).

Closes #1069

[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.

[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.

[newpavlov]

We could simplify the macro by removing the $(<$gp:ident: $bound:ident>)? part. Currently it's used only by gost94 and skein.

My initial intent was for this macro to support cases covered by the buffer_ct_variable macro, but, unfortunately, the required pattern becomes annoyingly complex, so I decided against it.

[baloo]

I've been upgrading downstream consumers of this crate (using this branch). I haven't found any usability issues.

[tarcieri]

I'm a bit confused by these macros calling themselves recursively. It makes the logic somewhat hard to follow. I guess that's to avoid having separate non-reusable macros for writing the various trait impls which would need to be part of the public API?

In general I'm eager to see this landed so I guess I won't hold it up, but I did want to note I found the macro expansions a bit hard to follow due to the large number of macro match arms.

[newpavlov]

@tarcieri
It's an unfortunate workaround for zipping behavior of declarative macros. We can't naively write the following code:

$(
    $crate::buffer_fixed!(
        impl_inner:
        $name$(<$gp: $bound>)?($core_ty);
        $trait_name
    );
)

Because it expects for $gp/$bound and $trait_name to repeat the same number of times (i.e. we get this error). As I wrote above, we could simplify it by removing $gp, but we need it not only for the two hash crates, but also for most of the MAC crates as well.

Maybe someone more familiar with declarative macros could write a better macro, but right now it's the best I could do.

[baloo]

anything else blocking here?

[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.

🤷