c92290278e base58: Close all errors (Tobin C. Harding)
Pull request description:
Currently we have a bunch of public errors in the `base58` crate. Only two are returned by public functions `decode()` and `decode_check()` (`Error` and `InvalidCharacterError` respectively).
- Close the two public errors by adding private inner errors.
- Add getters on the public errors to get the error data.
- Make all other errors private.
- Call `impl_from_infallible` for _all_ error types.
Done as part of #3261
ACKs for top commit:
apoelstra:
ACK c92290278eaa4b4f062928c6bc6c2984e1ab7ba6; successfully ran local tests
Tree-SHA512: e2ecef89691b41dfcc8ea3ef02c3719c45c72dbb252c76eadd97d03e32518ac7e00a2623d753de947d607ac3edf785f1ffdef8178a4f17ac3e7fd26ee01031ab
Currently we have a bunch of public errors in the `base58` crate. Only
two are returned by public functions `decode()` and
`decode_check()` (`Error` and `InvalidCharacterError` respectively).
- Close the two public errors by adding private inner errors.
- Add getters on the public errors to get the error data.
- Make all other errors private.
- Call `impl_from_infallible` for _all_ error types.
Done as part of #3261
We use `TBD` in our `deprecated` string and it was discovered that there
is an exception on this string so as not to warn because it is used
internally by the Rust language. However there is a special lint to
enable warnings, lets use it.
Add `#![warn(deprecated_in_future)]` to the coding conventions section
of all crates except `fuzz`.
If folk really want to index into a hash they can us `as_byte_array`
then index that.
Includes a bump to the version number of `hashes` to `v0.15.0` - this
is because otherwise `secp` won't build since we are breaking an API
that is used in the current release of secp.
Fix: #3115
Examples in documentation are not linted in the same way as other code,
but should still contain correctly written code.
Throughout all of the crates except internals (another commit) unused
variables have been prefixed with `_`, unused imports have been removed,
and a warn attribute added to all of the `lib.rs` files.
Done in an effort to reduce the cognitive load of reading the loop.
The base68 decode and encode algorithm uses a `u32` intentionally for
multiplication and a cast to `u8` intentionally when carrying.
Use `From` where possible and document the cast.
`d58` is the iterator value from `Bytes` (iter returned by
`String::bytes`). As such we can infallibly convert it using `from`.
Internal change only, no external changes.
dc96475f58 Add/fix alloc features (Tobin C. Harding)
Pull request description:
Eventually we would like all our crates other than `bitcoin` to be able to be used without an allocator. Currently, and during crate smashing, this is not that useful because so much of the code comes from `bitcoin` and relies on the availability of an allocator.
As an initial step, add the `alloc` feature to `addresses` , `base58`, and `primitives`.
In order to to keep `--no-default-features` builds working make the crates empty if the `alloc` feature is not enabled. This is a suboptimal solution because the error messages users will get when they forget to enable `alloc` will be confusing (eg something like primitives does not contain Transaction). However our CI script (`run_task.sh`) expects `--no-default-features` to build cleanly (as do I).
ACKs for top commit:
apoelstra:
ACK dc96475f58
Kixunil:
ACK dc96475f58
Tree-SHA512: 28006ad638e72d3c712becaf94f6aaddc559fb2f7e7ad0d0810348fe979fb61e32f53e5b20894e472c5ac9e2b7f80cba6a3f0e12b766b817f412a927957ae3a2
Most base58 strings in Bitcoin are somewhat short. There was previously
an "optimization" putting part of the input on stack which was removed
in #2759 because it actually made the code slower. This appears to be
mostly because of branches caused by using `iter::Chain`.
Manually splitting the iterations into two helped bring the performance
close to what #2759 achieved but that still wasn't worth it. But given
that we know the input length in many cases (it's just a slice) we can
determine whether it'll fit a buffer upfront and then just call
different functions which don't have the branches in loops. To avoid
having two functions this uses generics instead. Further, we increase
the buffer length to 128 and use `ArrayVec` from `internals` which
internally avoids initializing the buffer thanks to `MaybeUninit`
In total this increases performance by around 4% on my machine.
Eventually we would like all our crates other than `bitcoin` to be able
to be used without an allocator. Currently, and during crate smashing,
this is not that useful because so much of the code comes from `bitcoin`
and relies on the availability of an allocator.
As an initial step, add the `alloc` feature to `addresses` , `base58`,
and `primitives`.
In order to to keep `--no-default-features` builds working make the
crates empty if the `alloc` feature is not enabled. This is a suboptimal
solution because the error messages users will get when they forget to
enable `alloc` will be confusing (eg something like primitives does not
contain Transaction). However our CI script (`run_task.sh`) expects
`--no-default-features` to build cleanly (as do I).
Currently we have a trait `Hash` that is required for `Hmac`, `Hkdf`,
and other use cases. However, it is unegonomic for users who just want
to do a simple hash to have to import the trait.
Add inherent functions to all hash types including those created with
the new wrapper type macros.
This patch introduces some duplicate code but we are trying to make
progress in the hashes API re-write. We can come back and de-dublicate
later.
Includes making `to_byte_array`,`from_byte_array`, `as_byte_array`, and
`all_zeros` const where easily possible.
In preparation for improving the `base58` error types crate an `error`
module and move the single current error type there. Make the module
public and reexport the type.
Add a new `base58` crate to the workspace and move the `bitcoin::base58`
module to it.
Done as part of crate smashing, specifically so that we can make `bip32`
into a separate crate.