We have two macro definitions feature gated on `serde`. At some stage we
added the `doc(hidden)` attribute to one of them but forgot to add it to
the other. This technically makes our features non-additive. This macro
is "internal" so its unlikely that this is being used in the wild.
Add `doc(hidden)` to the `serde_impl` macro that is missing it.
Found by `cargo semver-checks` after recent upgrade to 0.38
We need to do a quick release because it turns out I was wrong in
thinking that making `hex` an optional dependency is not a breaking
change.
```
the package `bitcoin` depends on `bitcoin_hashes`, with features: `hex`
but `bitcoin_hashes` does not have these features. It has a required
dependency with that name, but only optional dependencies can be used as
features.
```
Add a changelog, bump the version, depend on the new version repo wide,
and update the lock files - like its our job.
To conform to Rust API guidelines examples should Examples use ?, not
try!, not unwrap (C-QUESTION-MARK).
Label the examples as `# Examples`.
Replace one `unwrap()` with `expect()` . The others don't technically
conform to the guidelines but are warranted.
The only reason we need `hex-conservative` is to parse strings and
format them as hex. For users that do not require this functionality we
can make the `hex-conservative` crate an optional dependency.
The `serde` feature requires `Display` so we enable `hex` from the
`serde` feature.
If `hex` feature is not enabled we still need to be able to debug so
provide `fmt::Debug` functionality by way of macros.
Close: #2654
For the `hashes` crate we would like to make `hex` an optional
dependency. In preparation for doing so do the following:
- Remove the trait bounds from `GeneralHash`
- Split the hex/string stuff out of `impl_bytelike_traits` into a
separate macro.
The `impl_bytelike_traits` macro is public and it is used in the
`hash_newtype` macro, also public.
Currently if a user calls the `hash_newtype` macro in a crate that
depends on `hashes` without the `serde` feature enabled and with no
`serde` dependency everything works. However if the user then adds a
dependency that happens to enable the `serde` feature in `hashes` their
build will blow up because `serde` code will start getting called from
the original crate's call to `hash_newtype`.
Pull the serde stuff out of `hash_newtype` and provide a macro to
implement it `impl_serde_for_newtype`.
1649b68589 Standardize wording to `constructs a new` (Jamil Lambert, PhD)
27f94d5540 Replace `creates` with `constructs` (Jamil Lambert, PhD)
Pull request description:
As discussed in issue #3575 there are various ways of saying a new object is created.
These have all be standardized to the agreed version.
Close#3575
ACKs for top commit:
apoelstra:
ACK 1649b68589834dfe9d5b63812da3e9f0e5930107; successfully ran local tests
tcharding:
ACK 1649b68589
Tree-SHA512: 0ed9b56819c95f1fc14da1e0fdbbe03c4af2d97a95ea6b56125f72913e8d832db5d2882d713ae139d00614e651f3834a4d72528bdf776231cceb6772bf2f9963
fe8ca21ec2 hashes: Duplicate impl_from_infallible (Tobin C. Harding)
7652d0ddfc hashes: Hide innards of FromSliceError (Tobin C. Harding)
5232bba62b hashes: Move FromSliceError to submodule (Tobin C. Harding)
Pull request description:
Hide the internals of the `hashes::FromSliceError`.
ACKs for top commit:
apoelstra:
ACK fe8ca21ec282cfe50e3f39b7f86c619d30d7f542; successfully ran local tests
Tree-SHA512: dac33777353dd81c8c86de331b2ab30d0a5268f2be7685f85405d29809ec36eeab31b0e71c9f09e820e06a93c3f05b7d675e5e729b780e8600b960cad4a02c77
There is a range of different wordings used in the docs of constructor
type functions.
Change all to start with `Constructs a new` or `Constructs an empty`.
In functions that act like constructors there is a mixture of the usage
of `creates` and `constructs`.
Replace all occurrences of `creates` with `constructs` in the first line
of docs of constructor like functions.
We don't want a dependency on `internals` for `hashes` unless its really
needed.
Duplicated the `impl_from_infallible` macro into `hashes::error` and
use it to implement from infallible for `FromSliceError`.
Add a public `error` module and move the one error for the `hashes`
crate into it.
Re-export at the crate root.
Done in preparation for adding an additional error type.
We have a couple of problems:
1. There are two macros currently for fmt stuff that do similar things,
`arr_newtype_fmt_impl` and `hex_fmt_impl` - the difference is not
immediately obvious, its the way that the byte array is iterated.
2. Our hash types are missing `AsRef<[u8; len]>` and `Borrow<[u8; len]>`.
Introduce a new macro and remove a bunch of other macros. Include
extensive docs but hide the macro from public docs because its not
really for consumers of the library.
The macro requires `$crate::hex` to point to `hex-conservative`.
Note the macro is pretty generic (as in general purpose), `hashes` might
not be the right home for it. Potentially a better place would be in
`hex` itself?
6aa8c2b023 Remove needless_borrows_for_generic_args (Tobin C. Harding)
Pull request description:
This has been fixed and we use nightly to lint so we have access to the merged fix.
ACKs for top commit:
apoelstra:
ACK 6aa8c2b023619534437043e76ec4252f27295875; successfully ran local tests
Tree-SHA512: 011677b6c1a2dc6c63097cafd1682fab5d9bdd94133b872bdd49699a55c80a01a8e6e5e844ae1cfe1ca9da47a2ba2ed6b910719b1ccbb06e60e22ecb01ec0efc
80b5d8b7b3 hashes: Add changelog for release 0.15.0 (Tobin C. Harding)
Pull request description:
The version has already been bumped on `master`.
In preparation for releasing `hashes v0.15.0` add a changelog entry.
ACKs for top commit:
apoelstra:
ACK 80b5d8b7b36ea97007f062971a732ec8a512cfa5; successfully ran local tests; again lots of stuff!
Tree-SHA512: ab1bbdf7df819c587dc905e4cdcda2232ede2a495a0e395e5d6f6bd730a7c3c0675e05f8ab616e5e6dee0a87836ab486d025f80608e73b713007391711ef15ba
This has been fixed and we use nightly to lint so we have access to the
merged fix.
Removing the attribute uncovers a bunch of real lint warnings, fix
them while we are at it.
We are about to release `bitcoin_hashes 0.15.0`, replace the TBD string
with the version number.
Requires changing `allow(deprecated_in_future)` attribute to
`allow(deprecated)` (in functions that are them self deprecated).
We have two files one for public macros and one for private macros. Move
the `engine_input_impl` macro to the private macros file.
Requires change to call sites because we do not have `use_macros`
attribute on the `internal_macros` file.
These three macros are solely provided to reduce code duplication, they
are only part of the public API because they are used by the "real"
public macro `hash_newtype`.
Roll the `serde_macros` module into `macros`, requires making `macros`
public but since it explicitly holds public macros this is reasonable.
Keep the original module and deprecate it.
The private and public modules are already grouped, add a line of
whitespace to make it _even_ more clear. Trivial I know, this patch got
smaller during rebase.
5ec17a2ee8 CI: Hobble WASM job (Tobin C. Harding)
Pull request description:
The WASM job is not working. `wasm-pack build` works fine but `wasm-pack test` doesn't compile.
Comment out the line that runs `wasm-pack test`.
ACKs for top commit:
apoelstra:
ACK 5ec17a2ee8c963d182777a9661b1bab786956bd4; successfully ran local tests; LGTM
Tree-SHA512: 5ea88bd99f625a8c669dc1dec02486dd549e9ac83d7670c6c7b3b25c86de3fc9a8dbc959dc39de92305dd5e254e0b8ed9424cae5e5941b66a6476ee433009fdd
1cb24c1f15 hashes:: Polish crate level rustdocs (Tobin C. Harding)
98691186dc hashes: Move engine functions (Tobin C. Harding)
12f261c009 hashes: Re-order from_byte_array (Tobin C. Harding)
c11587d60d hashes: Rename hash_type macro (Tobin C. Harding)
62617cf9ac hashes: Move from_engine function to other macro (Tobin C. Harding)
bb7dd2c479 hashes: Move DISPLAY_BACKWARD to top of impl block (Tobin C. Harding)
71013afe07 hashes: Put attribute under doc (Tobin C. Harding)
Pull request description:
`hashes 1.0.0` can't be far away, here is a quick polish (done while I waited for my car to get fixed).
Everything here is internal except stuff to docs. Note please I claim "internal change only" in a bunch of patches that do code moves but these effect the docs build because order is preserved in some instances.
ACKs for top commit:
apoelstra:
ACK 1cb24c1f150bc2d65d0be439f2005f41d95ad23c; successfully ran local tests
Tree-SHA512: 430c451afab8fc92fb4596bf2d4b36c086333fe72b3fe5858925b75597641b8c4f5e49f7643888fa19b675d3070ce9a3606623cd56bdba6cfc59e459fbdda440
The `sha256t` module is unique in that it implements its methods
manually (as call throughs) instead of using the macros. To make it more
clear what is implemented re-order the engine constructor and getter to
better mirror the layout in the macros.
Internal change only.
The `hashes` crate has a bunch of similar types defined by a bunch of
similar macros and impl blocks, all of which makes it difficult to tell
exactly what is implemented where. In an effort to make the code easier
to read order the `from_byte_array` constructor in the same place across
the crate. Note also we typically put constructors up the top, also
`from_byte_array` is the likely most used constructor so put it first.
FWIW I discovered this while polishing the HTML docs.
Internal change only.
Conceptually (and using traits) we split the hashes into "general"
hash types and more restricted hash types (`Hash`). Also we observe that
the `hash_type` macro defines all the inherent functions name
identically to the `GeneralHash` trait methods.
Rename the trait to describe better what it does.
Internal change only.
The `from_engine` function is associated with a general hash type but we
are defining it in the `hash_type` macro which holds nothing but
functions associated with the `Hash` trait. By "associated" I mean
methods on the type as opposed to trait methods.
In preparation for re-naming the `hash_type` macro move the
`from_engine` function there. Requires duplicating the code in the
`siphash` impl block, this is as expected because the `siphash` requires
a custom implementation of the general hashing functionality.
Internal change only.
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`.
We had an initial go at this but we didn't do the `Hash` trait method.
In order to do so we need to hack the serde code a fair bit, note the
public visitor types.
Tobin C. Harding
calciumbe
Jamil Lambert, PhD
merge-script
Leo Nash
Fmt Bot