The MSRV for the main crates is 1.65, which is higher than the Rust
version that stabilised workplace dependencies (1.64). The implicit MSRV
for the component crates is still lower than this, so we don't migrate
these crates.
`directories 5.0.1` added a dependency on `option-ext`, which is
licensed as MPL (a copyleft license). The replacement dependencies
are all licensed as `MIT OR Apache-2.0`.
This removes the `CommitmentTree`, `IncrementalWitness`, and
`MerklePath` types in favor of equivalent versions available
from the `incrementalmerkletree` crate.
This is in preparation for extraction into the `incrementalmerkletree`
crate, which is not Sapling-specific and therefore cannot hard-code
the depths of these data structures.
This removes our reliance on the following out-of-date transitive
dependencies that are duplicative of more recent versions of crates
we depend on:
- bls12_381 v0.7
- ff v0.12
- group v0.12
- jubjub v0.9
- pasta_curves v0.4
- reddsa v0.3
The `halo2_proofs/multicore` flag must be disabled when running wasm
builds; this ensures that we do not accidentally include it as a
transitive dependency when building with `--no-default-features`.
The MSRVs of the component crates are left as-is, partly because our
dependencies don't require us to bump them, and partly because those
crates have no pending changes and are relatively stable. We also plan
to split the component crates out into a separate repository, where it
will be easier to have a separate MSRV.
Closeszcash/librustzcash#759.
The implementation of `io:Read` for `ResponseLazyReader` used to return
only one byte regardless of the size of the provided `buf`, which
significantly degraded the performance of loading the response.
This change makes use of the provided `buf`. On my machine with Rust
1.64, the downloading speed went up from ~100 KiB/s to ~2 MiB/s.
However, as before this change, the process still uses 100% of a single
CPU thread when downloading the response. The most likely reason is that
we still manually read each byte of the response. I can download the
same data with ~ 50 MiB/s on my machine using a different HTTP client.
This fix seems to be sufficient for now.
Jack Grigg
Kris Nuttycombe
Marek
Sean Bowe