| Age | Commit message (Collapse) | Author |
|---|
|
I haven't developed this experimental code any further since I pushed
it, and it's not good for unused code to sit around. If I ever get back
to this project I might revert this deletion.
|
|
|
|
This is currently driven by dependencies of ciborium, which is itself a
dev dependency. It's not really a crate MSRV bump.
|
|
This is the current MSRV of `cc`.
|
|
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.)
|
|
|
|
|
|
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`.
|
|
|
|
|
|
|
|
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.
|
|
https://twitter.com/burntsushi5/status/1695483429997945092
https://github.com/rust-lang/compiler-team/issues/648
|
|
As usual, the driver here is the MSRV of clap. I should've checked this
when I updated the Cargo.lock file.
|
|
|
|
This bumps the MSRV of both `blake3` and `b3sum` to 1.66.1.
|
|
|
|
Aggreggate source files directly in the target instead of a proxy
variable.
Install CMake package config files in order to allow the project to be
found via `find_package()` by dependents.
Replace hard coded SIMD compiler flags with configurable options. Retain
the current GCC/Clang flags as defaults for these compilers. Add default
SIMD compiler flags for MSVC.
Remove hard coded compiler flags (including -fPIC). These are not
portable and should be set by the toolchain file or on the CLI.
- Guard ASM sources with triplet compatibility checks.
- Remove the `BLAKE3_STATIC` option in favor of [`BUILD_SHARED_LIBS`].
[`BUILD_SHARED_LIBS`]: https://cmake.org/cmake/help/v3.9/variable/BUILD_SHARED_LIBS.html
|
|
|
|
|
|
|
|
While we're at it, black format the .py files in this directory.
|
|
|
|
|
|
|
|
|
|
I'm not sure how to build for Apple Silicon from a Linux host, but it
seems to work as-is from an x86_64 macOS host. Alas, GitHub doesn't yet
provide Apple Silicon hosts to run these binaries, and Cross doesn't yet
support virtualizing them either.
|
|
|
|
|
|
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.)
|
|
This approach was suggested by @tarcieri at
https://github.com/BLAKE3-team/BLAKE3/pull/157.
|
|
|
|
This will let us add big endian testing to CI for our C code. (We were
already doing it for our Rust code.)
This is adapted from test_vectors/cross_test.sh. It works around the
limitation that the `cross` tool can't reach parent directories. It's an
unfortunate hack, but at least it's only for testing. It might've been
less hacky to use symlinks for this somehow, but I worry that would
break things on Windows, and I don't want to have to add workarounds for
my workarounds.
|
|
|
|
Samuel noticed that rustc seems to assume (incorrectly?) that all i686
targets support SSE2, but it doesn't make that assumption for i586.
|
|
This is quite hard to trigger, because SSE2 has been guaranteed for a
long time. But you could trigger it this way:
rustup target add i686-unknown-linux-musl
RUSTFLAGS="-C target-cpu=i386" cargo build --target i686-unknown-linux-musl
Note a relevant gotcha though: The `cross` tool will not forward
environment variables like RUSTFLAGS to the container by default, so if
you're testing with `cross` you'll need to use the `rustc` command to
explicitly pass the flag, as I've done here in ci.yml. (Or you could
create a `Cross.toml` file, but I don't want to commit one of those if I
can avoid it.)
|
|
|
|
As proposed in
https://github.com/BLAKE3-team/BLAKE3/issues/33#issuecomment-623153164
This brings b3sum behavior close to md5sum. All occurrences of backslash
are replaced with "\\", and all occurrences of (Unix) newline are
replaced with "\n". In addition, any line containing these escapes has a
single "\" prepended to the front.
Filepaths were already being converted to UTF-8 with to_string_lossy(),
but this commit adds an extra warning when that conversion is in fact
lossy (because the path is not valid Unicode). This new warning is
printed to stdout, with the goal of deliberately breaking --check (which
is not yet implemented) in this case.
|
|
These configs and code are adapted from the CI workflow in
https://github.com/oconnor663/blake3-py, especially the
upload_github_release_asset.py script, which is copied verbatim.
|
|
|
|
|
|
There are two scenarios where compiling AVX-512 C or assembly code might
not work:
1. There might not be a C compiler installed at all. Most commonly this
is either in cross-compiling situations, or with the Windows GNU
target.
2. The installed C compiler might not support e.g. -mavx512f, because
it's too old.
In both of these cases, print a relevant warning, and then automatically
fall back to using the pure Rust intrinsics build.
Note that this only affects x86 targets. Other targets always use pure
Rust, unless the "neon" feature is enabled.
|
|
|
|
This lets CI test a wider range of possible SIMD support settings.
|
|
The biggest change here is that assembly implementations are enabled by
default.
Added features:
- "pure" (Pure Rust, with no C or assembly implementations.)
Removed features:
- "c" (Now basically the default.)
Renamed features;
- "c_prefer_intrinsics" -> "prefer_intrinsics"
- "c_neon" -> "neon"
Unchanged:
- "rayon"
- "std" (Still the only feature on by default.)
|
|
|
|
|
|
|
|
|
|
|
