Changes since 1.5.2:
- Revert the serialization change. It was intended to be backwards
compatible, but that didn't hold for non-self-describing serialization
formats like bincode. See #414.
This mostly reverts commits 8416b1658c2690dc6351bdc7e0975b0d5f1a5282 and
dd0afd640ad97b5ebcf887107162009a23ffdca0.
Changing the serialization of Hash can only be backwards-compatible in
self-describing formats like CBOR. In non-self-describing formats like
bincode, the deserializer has to know in advance which serialization
format was used.
Fixes https://github.com/BLAKE3-team/BLAKE3/issues/414.
Reopens https://github.com/BLAKE3-team/BLAKE3/issues/412.
Changes since 1.5.1:
- `build.rs` sets `cc::Build::emit_rerun_if_env_changed(false)` to
prevent some unnecessary rebuilds, particularly when the `PATH`
changes on Windows. See #324.
- Serializing a `Hash` produces a bytestring instead of an array in
formats that support bytestrings (like CBOR). Deserialization is
backwards-compatible with the array format.
- Cleanup and edge case fixes in the C and CMake builds.
Add a symbolic link to the top-level license file; this is dereferenced
by cargo publish, and the LICENSE appears as a regular file in the
published crate.
Changes since 1.5.0:
- The Rust crate is now compatible with Miri.
- ~1% performance improvement on Arm NEON contributed by @divinity76 (#384).
- Various fixes and improvements in the CMake build.
- The MSRV of b3sum is now 1.74.1. (The MSRV of the library crate is
unchanged, 1.66.1.)
vld1q_u8 and vst1q_u8 has no alignment requirements.
This improves performance on Oracle Cloud's VM.Standard.A1.Flex by 1.15% on a 16*1024 input, from 13920 nanoseconds down to 13800 nanoseconds (approx)
Basically all of the `actions-rs/*` actions are unmaintained. See
<https://github.com/actions-rs/toolchain/issues/216> for more
information. Due to their age they generate several warnings in
CI runs.
To get rid of those warnings the occurrences of
`actions-rs/toolchain` are replaced by `dtolnay/rust-toolchain`.
Specify language requirement as a [compile-feature] and force compiler
extensions off ensuring portability problems are detected early on.
Note that we do not use the `C_STANDARD` property, because it doesn't
propagate to dependent targets and would prohibit users from compiling
their code base with consistent flags / language configuations if they
were to target a newer C standard. Similarly we do not configure
`C_STANDARD_REQUIRED` as [compile-features] do not interact with
it--they are enforced regardless.
[compile-feature]: https://cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html#compile-feature-requirements
