Previously we only disabled these warnings for SSE2, which is assumed
enabled on x86-64, but it looks like new nightly compilers are also
assuming SSE4.1 on macOS. Disabling these warnings across all the
detection functions accounts for that, and it also gets rid of some
warnings that you'd see if you used RUSTFLAGS='-C target-cpu=native'.
This makes them consistent with how the existing update() and
update_rayon() methods work, with the difference being that it's it's
io::Result<&mut Self> instead of just &mut Self.
New methods:
- update_reader
- update_mmap
- update_mmap_rayon
These are more discoverable, more convenient, and safer.
There are two problems I want to avoid by taking a `Path` instead of a
`File`. First, exposing `Mmap` objects to the caller is fundamentally
unsafe, and making `maybe_mmap_file` private avoids that issue. Second,
taking a `File` raises questions about whether memory mapped reads
should behave like regular file reads. (Should they respect the current
seek position? Should they update the seek position?) Taking a `Path`
from the caller and opening the `File` internally avoids these
questions.
I'm adding the i32::MAX test case here because I personally screwed it
up while I was working on
https://github.com/BLAKE3-team/BLAKE3/issues/271. The correct
implementation of the carry bit is the ANDNOT of old high bit (1) and
the new high bit (0). Using XOR instead of ANDNOT gives the correct
answer in the overflow case, but it also reports an incorrect "extra"
overflow when the high bit goes from 0 to 1.
Adjust to the following changes that happened in digest:
- The crypto-mac crate has been merged into digest (with "mac" feature
enabled)
- Various traits have been split up
- The Digest and Mac traits now share their update/finalize/reset
implementations
- The BlockInput trait was dropped without replacement apparently (as
long as the low-level core API is not used)
The SSE2 patch introduced xmm10 as a temporary register for one of the
rotations, but xmm6-xmm15 are callee-save registers on Windows, and
SSE4.1 was only saving the registers it used. The minimal fix is to use
one of the saved registers instead of xmm10.
See https://github.com/BLAKE3-team/BLAKE3/issues/206.
These clutter the toplevel API, and their prominence might lead callers
to prefer them as a first resort, which probably isn't a good idea.
Restricting multithreading to `Hasher::update_rayon` feels better,
similar to what we've done with `Hasher::finalize_xof`. (But I think
`update_rayon` is still an improvement over the trait-based interface
that it replaced.)