Add a `bitcoin_io` crate
In order to support standard (de)serialization of structs, the
`rust-bitcoin` ecosystem uses the standard `std::io::{Read,Write}`
traits. This works great for environments with `std`, however sadly
the `std::io` module has not yet been added to the `core` crate.
Thus, in `no-std`, the `rust-bitcoin` ecosystem has historically
used the `core2` crate to provide copies of the `std::io` module
without any major dependencies. Sadly, its one dependency,
`memchr`, recently broke our MSRV.
Worse, because we didn't want to take on any excess dependencies
for `std` builds, `rust-bitcoin` has had to have
mutually-exclusive `std` and `no-std` builds. This breaks general
assumptions about how features work in Rust, causing substantial
pain for applications far downstream of `rust-bitcoin` crates.
Here, we add a new `bitcoin_io` crate, making it an unconditional
dependency and using its `io` module in the in-repository crates
in place of `std::io` and `core2::io`. As it is not substantial
additional code, the `hashes` io implementations are no longer
feature-gated.
This doesn't actually accomplish anything on its own, only adding
the new crate which still depends on `core2`.
2023-10-04 05:51:26 +00:00
|
|
|
//! Rust-Bitcoin IO Library
|
|
|
|
//!
|
|
|
|
//! Because the core `std::io` module is not yet exposed in `no-std` Rust, building `no-std`
|
|
|
|
//! applications which require reading and writing objects via standard traits is not generally
|
|
|
|
//! possible. While there is ongoing work to improve this situation, this module is not likely to
|
|
|
|
//! be available for applications with broad rustc version support for some time.
|
|
|
|
//!
|
|
|
|
//! Thus, this library exists to export a minmal version of `std::io`'s traits which `no-std`
|
|
|
|
//! applications may need. With the `std` feature, these traits are also implemented for the
|
|
|
|
//! `std::io` traits, allowing standard objects to be used wherever the traits from this crate are
|
|
|
|
//! required.
|
|
|
|
//!
|
|
|
|
//! This traits are not one-for-one drop-ins, but are as close as possible while still implementing
|
|
|
|
//! `std::io`'s traits without unnecessary complexity.
|
|
|
|
|
|
|
|
// Experimental features we need.
|
|
|
|
#![cfg_attr(docsrs, feature(doc_auto_cfg))]
|
|
|
|
|
|
|
|
#![cfg_attr(not(feature = "std"), no_std)]
|
|
|
|
|
|
|
|
#[cfg(all(not(feature = "std"), not(feature = "core2")))]
|
|
|
|
compile_error!("At least one of std or core2 must be enabled");
|
|
|
|
|
|
|
|
#[cfg(feature = "std")]
|
|
|
|
pub use std::error;
|
|
|
|
#[cfg(not(feature = "std"))]
|
|
|
|
pub use core2::error;
|
2023-09-09 23:31:48 +00:00
|
|
|
|
|
|
|
#[cfg(any(feature = "alloc", feature = "std"))]
|
|
|
|
extern crate alloc;
|
|
|
|
|
|
|
|
/// Standard I/O stream definitions which are API-equivalent to `std`'s `io` module. See
|
|
|
|
/// [`std::io`] for more info.
|
|
|
|
pub mod io {
|
|
|
|
#[cfg(all(not(feature = "std"), not(feature = "core2")))]
|
|
|
|
compile_error!("At least one of std or core2 must be enabled");
|
|
|
|
|
|
|
|
#[cfg(feature = "std")]
|
2023-09-12 17:45:08 +00:00
|
|
|
pub use std::io::{Read, Write, sink, Cursor, Take, Error, ErrorKind, Result};
|
2023-09-09 23:31:48 +00:00
|
|
|
|
|
|
|
#[cfg(not(feature = "std"))]
|
|
|
|
pub use core2::io::{Read, Write, Cursor, Take, Error, ErrorKind, Result};
|
|
|
|
|
|
|
|
|
|
|
|
}
|