Commit Graph

14 Commits

Author SHA1 Message Date
Tobin C. Harding 3ca55fb163
Remove qualifying path from Read and Write
There is no advantage in having `io::Read` as opposed to `Read` and
importing the trait. It is surprising that we do so.

Remove `io::` path from `io::Read` and `io::Write`. Some docs keep the
path, leave them as is. Add import `use io::{Read, Write}`.

Refactor only, no logic changes.
2023-12-12 11:48:29 +11:00
Tobin C. Harding f764a607ac
Use conventional import path for io crate
We have a convention in `rust-bitcoin` to use external crates directly
when importing them not via `crate::foo`.

Update all the import paths for `io` to use this form.
2023-11-29 08:48:03 +11:00
Tobin C. Harding 761de886be
Remove imports of TryFrom and TryInto
Now that MSRV is Rust 1.56.1 we no longer need to explicitly import
`TryFrom` and `TryInto`.

No clue why clippy didn't find these for us.
2023-11-24 03:52:05 +11:00
Matt Corallo 141343edb4 [IO] Move to custom `Read` trait mirroring `std::io::Read`
In order to move towards our own I/O traits in the `rust-bitcoin`
ecosystem, we have to slowly replace our use of the `std` and
`core2` traits.

Here we take the second big step, replacing
`{std,core2}::io::Read` with our own `bitcoin_io::io::Read`. We
provide a blanket impl for our trait for all `std::io::Read`, if
the `std` feature is enabled, allowing users who use their own
streams or `std` streams to call `rust-bitcoin` methods directly.
2023-11-07 05:51:39 +00:00
Matt Corallo 7395093f94 Stop relying on `Take`'s `by_ref` method 2023-11-07 05:51:37 +00:00
Andrew Poelstra eab9f89779
Merge rust-bitcoin/rust-bitcoin#1986: Remove private hex test macro
8eff4d0385 Remove private hex test macro (Tobin C. Harding)

Pull request description:

  We have this macro in `hex-conservative` now, remove the version here.

  This patch does not change the public API and only touches test code.

ACKs for top commit:
  apoelstra:
    ACK 8eff4d0385
  clarkmoody:
    ACK 8eff4d0385

Tree-SHA512: 93a08fff778930071cd1a28c19202e4a94ca8881b2e873538de2e942b71c2cd6184ed6364c572538a8a699295a71761c6f836accaf251a15683138b71f148fab
2023-10-06 22:14:12 +00:00
Tobin C. Harding 10374af75c
Make error types uniform
On our way to v1.0.0 we are defining a standard for our error types,
this includes:

- Uses the following derives (unless not possible, usually because of `io::Error`)

  `#[derive(Debug, Clone, PartialEq, Eq)]`

- Has `non_exhaustive` unless we really know we can commit to not adding
  anything.

Furthermore, we are trying to make the codebase easy to read. Error code
is write-once-read-many (well it should be) so if we make all the error
code super uniform the users can flick to an error and quickly see what
it includes. In an effort to achieve this I have made up a style and
over recent times have change much of the error code to that new style,
this PR audits _all_ error types in the code base and enforces the
style, specifically:

- Is layed out: definition, [impl block], Display impl, error::Error impl, From impls
- `error::Error` impl matches on enum even if it returns `None` for all variants
- Display/Error impls import enum variants locally
- match uses *self and `ref e`
- error::Error variants that return `Some` come first, `None` after

Re: non_exhaustive

To make dev and review easier I have added `non_exhaustive` to _every_
error type. We can then remove it error by error as we see fit. This is
because it takes a bit of thinking to do and review where as this patch
should not take much brain power to review.
2023-10-04 15:15:52 +11:00
Tobin C. Harding 2512dbafc2
Remove impl_std_error macro
We would like the codebase to be optimized for readability not ease of
development, as such code that is write-once-read-many should not use
macros.

Currently we use the `impl_std_error` macro to implement
`std::error::Error` for struct error types. This makes the code harder
to read at a glance because one has to think what the macro does.

Remove the `impl_std_error` macro and write the code explicitly.
2023-10-04 15:15:34 +11:00
Tobin C. Harding 8eff4d0385
Remove private hex test macro
We have this macro in `hex-conservative` now, remove the version here.

This patch does not change the public API and only touches test code.
2023-09-30 06:22:52 +10:00
Tobin C. Harding 0419fa278b
Add VarInt from implementations by way of macro
Throughout the codebase we cast values to `u64` when constructing a
`VarInt`. We can make the code marginally cleaner by adding `From<T>`
impls for all unsigned integer types less than or equal to 64 bits.
Also allows us to (possibly unnecessarily) comment the cast in a single
place.
2023-08-24 10:37:53 +10:00
Tobin C. Harding d4e8f49fc3
Move p2p::constants::Network to crate root
The `Network` type is not a p2p construct, it is more general, used
throughout the codebase to define _which_ Bitcoin network we are
operating on.
2023-08-01 16:46:59 +10:00
Tobin C. Harding 0f78943ef0
Move p2p::constants::Magic to p2p module
In preparation for removing the `p2p::constants` module; move the
`p2p::constants::Magic` type to the `p2p` module.
2023-08-01 16:42:05 +10:00
Tobin C. Harding d9d5a4ed4f
Move p2p::constants::ServiceFlags to p2p module
The `ServiceFlags` type is used by the p2p layer. It can live in the
`mod.rs` file of the `p2p` module. Done in preparation for removing the
`p2p::constants` module.

This is a straight code move, the `ServiceFlags` replaces the
current re-export.
2023-08-01 16:36:12 +10:00
Tobin C. Harding 1bac1fd518
Rename the network module to p2p
The `network` module deals with data types and logic related to
internetworking bitcoind nodes, this is commonly referred to as the p2p
layer.

Rename the `network` module to `p2p` and fix all the paths.
2023-08-01 16:36:12 +10:00
Renamed from bitcoin/src/network/message.rs (Browse further)