This documents the Cargo features making sure docs.rs shows warning for
feature-gated items. They are also explicitly spelled out in the crate
documentation.
With the introduction of Schnorr signatures, exporting a `Signature`
type without any further qualification is ambiguous. To minimize the
ambiguity, the `ecdsa` module is public which should encourage users
to refer to its types as `ecdsa::Signature` and `ecdsa::SerializedSignature`.
To reduce ambiguity in the APIs on `Secp256k1`, we deprecate several
fucntions and introduce new variants that explicitly mention the use of
the ECDSA signature algorithm.
Due to the move of `Signature` and `SerializedSignature` to a new module,
this patch is a breaking change. The impact is minimal though and fixing the
compile errors encourages a qualified naming of the type.
24d6f62603 Use explicit u8 when assigning a byte slice (junderw)
Pull request description:
Is there a way to tell the compiler to not allow `[0; 64]` and require that either the type is explicitly given to the variable, or that each member uses explicit `0u8` notation?
I noticed the usage was a mix of explicit and implicit, so I changed all to explicit.
ACKs for top commit:
apoelstra:
ACK 24d6f62603
Tree-SHA512: f7796dcc3ae240983257bef0f25bd0df741943f75d86e9bca7c45076af179d96ce213bd9c339a01f721f7dc9b96a0a4a56ef2cf44339f4c91d208103b7659d9f
Panicking from C is not UB in newer rust versions and will reliably
trigger an abort (without unwinding). In older rust versions, it is
technically UB but empirically it seems to "just work" (and what should
it realistically do except crashing, which is what we intent).
Since there's potentially no unwinding, we can't test this behavior
using [should_panic]. This PR will instead check the libtest output
explicitly in our CI tests.
Fixes#228.
There is little reason to pull in the `rand` dep just for the `Rng`
trait for users who want to randomize contexts. We should expose a
randomize function that just takes 32 bytes.
We can now run unit tests with the fuzz feature on, and they'll pass,
which is some assurance that fuzzing with the feature on won't lead to
spurious failures due to the fuzz harness inadequately simulating message
signing.
Instead of repeating ourselves in defining one big test for the wasm
target, we can override the `test` attribute with the `wasm-bindgen-test`
one and therefore automatically run all (supported) tests in wasm.
Unfortunately, wasm doesn't support catching panics yet which means we
have to disable the `test_panic_raw_ctx` test.
libsecp256k1 really only barely uses libc at all, and in practice,
things like memcpy/memcmp get optimized into something other than a
libc call. Thus, if we provide simple stub headers, things seem to
work with wasm-pack just fine.