Commit Graph

7 Commits

Author SHA1 Message Date
Tobin C. Harding 53d75c7b94
extended_tests: Remove stale docs
We no longer need to pin `syn`; remove stale docs.
2023-04-20 09:17:10 +10:00
Andrew Poelstra 8440d80a5a
Merge rust-bitcoin/rust-bitcoin#1696: Remove `schemars` pin from manifest
6c61e1019e Fix pinning (schemars and MSRV) (Tobin C. Harding)
c8e38d6a5a hashes: Implement JsonSchema for sha256t::Hash<T> (Tobin C. Harding)

Pull request description:

  This has grown due to now including pinning work also done in https://github.com/rust-bitcoin/rust-bitcoin/pull/1736, I decided to do this because the PRs conflict and doing it all here saves accidentally getting out of sync. And  https://github.com/rust-bitcoin/rust-bitcoin/pull/1764 requires this PR.

  - Patch 1 is unchanged
  - Patch 2 now fixes pinning in bitcoin and hashes CI scripts and in the docs of both as well as the manifest stuff relating to `schemars` - phew.

  Fix: #1687

ACKs for top commit:
  Kixunil:
    ACK 6c61e1019e
  apoelstra:
    ACK 6c61e1019e

Tree-SHA512: eae4aa9700817bab6ad444e07709e8b1a4ffb1625e08be6ba399abde38bf6f8e5ea216a0836e2e26dfaddc76c392802cd016738ea6e753a1bca2584d9d2a9796
2023-04-19 22:18:29 +00:00
Tobin C. Harding 6c61e1019e
Fix pinning (schemars and MSRV)
Done as is single patch to make sure all the docs and CI are in sync and
correct.

We currently pin the `schemars` dependency using `<=0.8.3` as well as a
the `dyn-clone` transient dependency in the manifest (`hashes` and the
extended test crate). This is incorrect because it makes usage of the
crate klunky (or possibly impossible) if downstream users wish to use a
later version of `schemars`.

Observe also that we do not have to pin `schemars`, we do however have to pin
the `serde` crate if either `serde` or `schemars` features are enabled.
Do so in CI and document in the readme file within hashes.

Currently we have a pin remaining from the old MSRV (`syn` due to use
of `matches!`).

Fix pinning by:

- Remove pin in manifest for `schemars`
- Fix pinning for MSRV in CI and docs (this includes documenting pinning
  requirements for `schemars` feature because it is related to the other
  pin of `serde`) in both `hashes` readme and main repo readme.
2023-04-19 10:17:18 +10:00
Martin Habovstiak 095b7958dd Make `sha256t_hash_newtype!` evocative of the output.
The Rust API guidelines state that macros should be evocative of the
output, which is a sensible recommendation. We already had this for
`hash_newtype!` macro but didn't for sha256t version.

This changes the macro to have this syntax:

```rust
sha256t_hash_newtype! {
    // Order of these structs is fixed.
    /// Optional documentation details here. Summary is auto-generated.
    /*pub*/ struct Tag = raw(MIDSTATE_BYTES, LEN);

    /// Documentation here
    #[hash_newtype(forward)] // optional, default is backward
    /*pub*/ struct HashType(/* attributes allowed here */ _);
}
```

Closes #1427
2023-04-02 17:00:52 +02:00
Tobin C. Harding 161273b209
Re-name hash inner/byte methods
Currently we have an associated type on hash types `Inner` with
accompanying methods `into_inner`, `from_inner`, `as_inner`. Also, we
provide a way to create new wrapped hash types. The use of 'inner'
becomes ambiguous with the addition of wrapped types because the inner
could be the inner hash type or the `Inner` byte array of the inner
wrapped hash type.

In an effort to make the API more clear and uniform do the following:

- Rename `Inner` -> `Bytes`
- Rename `*_inner` -> `*_byte_array`
- Rename the inner hash to/from methods to `*_raw_hash`

Correct method prefix `into_` -> `to_` because theses methods convert
owned `Copy` types.

Add the trait Bound `Copy` to the `Bytes` type because we rely on this
trait bound for the conversion methods to be correctly named according
to convention.

Because of the dependency hole created by `secp256k1` this patch changes
the secp dependency to a git tag dependency that includes changes to the
hashes calls required so that we can get green lights on CI in this
repo.
2023-02-27 14:23:58 +11:00
Martin Habovstiak 06f1f027ab Make `hash_newtype` evocative of the output
The API guidelines say macro input should be evocative of the output.
`hash_newtype` didn't have this property.

This change makes it look exactly like the resulting struct, `$len`
parameter was removed since it's not needed, reversing is controlled
using an attribute. The macro is also better documented and ready to be
extended in the future.

The tagged SHA256 newtype is not yet modified because it has a more
complicated input parameters.

Closes #1648
2023-02-22 14:35:50 +01:00
Tobin C. Harding b9643bf3e9 Import bitcoin_hashes crate into hashes
We would like to bring the `bitcoin_hashes` crate into the
`rust-bitcoin` repository.

Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all
the commit history from the original crate but if we archive the
original repository then the history will be preserved. We maintain the
same version number obviously and in the changelog we note the change of
repository.

Commit hash that was tip of `bitcoin_hashes` at time of import:

 commit 54c16249e06cc6b7870c7fc07d90f489d82647c7

Includes making `embedded` and `fuzzing` per-crate i.e., move them into
`bitcoin` as hashes includes these also.

NOTE: Does _not_ enable fuzzing for `hashes` in CI.

Notes on CI:

Attempts to merge in the github actions from the hashes crate however reduces
coverage by not running hashes tests for beta toolchain. Some additional
work could be done to improve the CI to increase efficiency without
reducing coverage. Leaving for another day.
2022-11-08 08:58:09 +11:00