Upgrades the edition, with changes primarily performed by
`cargo fix --edition`.
In order to keep the changes to a minimum, this doesn't include
automated idiom fixes (i.e. `cargo fix --edition-idioms`).
This is needed to unblock the edition upgrade for the RSA crate:
https://github.com/RustCrypto/RSA/pull/135
* no_std support
* Use integer log2 when possible to estimate allocations
* Remove std features from a few dependencies
* Use libm for missing funcs in nostd environment
* Use autocfg to detect presence of i128
* Better CI test for nostd environment
* Move benchmark to a separate crate
* Make the tests pass in no_std builds
* Use thumbv7m target for nostd build test
* Add documentation about the no-std compatibility
* Make zeroize and prime features no_std-compatible
* Test each feature in nostd context
* Fix mac test to work in no_std environment
* Avoid using thread_rng in nostd tests
* Fix prime tests in nostd mode
* Fix all warnings and errors
* Only test nostd builds on nightly on travis
* Travis: Only do nostd builds on nightly
This commit overrides default implementations of
Roots::sqrt and Roots::cbrt for BigInt and BigUint
with optimized ones. It also improves tests and
resolves minor inconsistencies.
Signed-off-by: Manca Bizjak <manca.bizjak@xlab.si>
This commit implements num-integer::Roots trait
for BigInt and BigUint types, and also adds sqrt,
cbrt, nth_root as inherent methods to allow access
to them without importing Roots trait. For each
type tests were added as submodules in the roots
test module.
Signed-off-by: Manca Bizjak <manca.bizjak@xlab.si>
The *idea* of `big_digit` and its type aliases is that we may someday
use something other than `u32` in the representation, perhaps even
different sizes for different targets. That's still a possibility, but
I think it's not really feasible to expose this variation in the public
API. Calling `BigUint::from_slice([1, 2, 3])` is only meaningful if you
know what that size is, and users can't really alternate this kind of
thing based on a type definition. So for now, we just commit to `u32`
units in the public API, no matter what we may do internally.
This removal is a breaking change, part of the 0.2 semver bump. If I'm
wrong and somebody can show a compelling use case for `big_digit`, we
can always add things back into the public API later.
The test modules were getting huge, and some of its functions were
actually a huge amount of code due to macros, causing tests to take a
long time just to compile. They are now separated into a few different
tests, and the scalar macros especially are now expanded more sparingly
in just a few `check()` functions.
Test compile times for me went from about 25 seconds to 1.5s in debug
mode, and from 300 seconds (!) to about 8s in release mode.
This performs modular exponentiation on signed `BigInt`. The exponent
must be positive, and the modulus must be non-zero. The implementation
leverages `BigUint::modpow`, fixing the signs as needed afterward.
