As pointed out by @ruuda:
> This is more of a problem with `#[feature]` in Rust; once a feature becomes
> stable, having `#[feature]` becomes an error, so it is not easy to depend on a
> feature on nightly, and then have the same code work on stable once the feature
> is stabilized.
The earliest `byteorder` version without a `#[feature]` is `1.2.3`, so we
require any higher version than that one.
Closes#184.
Closes#186.
This change provides a common convention for using allocator-dependent
features with:
#![cfg(feature = "alloc")]
When available, `Vec` is imported consistently as `prelude::Vec`, which
means modules that need access to `Vec` can simply do:
use prelude::*;
and if an allocator is available, `Vec` will be in the crate prelude.
This allows all `alloc` vs `std` gating to be handled in `lib.rs`,
`build.rs`, and `prelude.rs` so the rest of the codebase doesn't have to
do any gating whatsoever.
Unfortunately, Rust selects `i32` as the type for an integer literal
when the literal has no other type constraints. This means that someone
cannot write `Scalar::from(1)`, as Rust will choose `i32` as the type for
`1`, and we don't `impl From<i32> for Scalar`.
We could implement `From` conversions for signed integers, but since
`Scalar` operations should be constant-time by default, this would
require us to extract the sign bit of the integer and use it to
conditionally select between the positive and negative of Scalar
constructed from the value bits. This is more expensive than the
unsigned operation, and I don't think it's what anyone really wants.
Making API consumers specify that their literals are unsigned is
slightly annoying, but better than the above alternative.
It would also be nice to change `Scalar::from_hash` to be
`impl<D: Digest<OutputSize = U64>> From<D> for Scalar`,
but this isn't currently allowed by Rust (since that `impl` "could"
conflict with the `impl From<u8>` if someone decided that `u8` should
`impl Digest`).
Each backend can now be selected by an individual feature:
- `u32_backend` for `backend::u32`;
- `u64_backend` for `backend::u64`;
- `avx2_backend` for `backend::avx2`;
The `u64_backend` is selected by default, since most people use X64 and we have
no way to select based on target (see discussion in #126). However, these
changes mean that it is possible to select the backend explicitly, and if we
had the ability to select target-default features, we could do so easily.
Change Scalar::non_adjacent_form() to take a width parameter.
This rewrite also makes it faster, although it's probably a ways off
from optimal. I don't know how much it matters.
TODO: write up description of why this computes the same thing.
Thanks to @oleganza for pointing out an error reading bits across words
in an earlier version of this code.
This change required some work, because the to-be-stabilized SIMD functions
don't allow non-constant `imm8`s. Previously, the `stdsimd` functions had a
constifying macro that ensured that the immediates were known. The dalek code
used this to build helper functions which would be inlined into different
places where the immediates were known. Unfortunately, since constexprs aren't
fully supported in Rust yet, this is done by a hidden compiler attribute, and
there's no way to propagate "constness".
To deal with this, some of the functions are specialized (e.g.,
`square_and_negate_D` instead of taking a mask), and others use an enum.
Since Criterion can only benchmark public API, these changes just drop
all internal benchmarks (e.g., benchmarks for field operations). But
those are usually microbenchmarks whose meaning is kind of questionable
anyways, so I don't think this is a big loss.
The `bench` feature disappears, since Criterion works on stable Rust.
These all have the default values, except for the "yolocrypto" requirement in
the test section, which is already covered by CI and which doesn't do what we
want anyways -- it does not enable the feature if it's not there.
libcollections was recently merged into liballoc:
https://github.com/rust-lang/rust/pull/42648
I went ahead and also added an "alloc" feature which no_std users can use to opt
into liballoc features (i.e. any code using Vec). This should have no effect on
anything but no_std usage. It does make it possible for people without
allocators to use curve25519-dalek if they want though. Might be nice for
"bare metal" development.
All that said, from what I can gather liballoc, while not "stable", should
likely stick around for the forseeable future.
Some backstory on the liballoc/libcollections merge here:
https://github.com/rust-lang/rust/pull/42565
