Build breaks for `--no-default-features --features serde`

[tnull]

When neither std nor no-std are present but serde is selected, the build breaks with a lot of error along the lines:

> cargo build --no-default-features --features serde
   Compiling miniscript v9.0.0 (/Users/ero/workspace/rust-miniscript)
error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?
   --> src/lib.rs:100:1
    |
100 | extern crate hashbrown;
    | ^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: see issue #27812 <https://github.com/rust-lang/rust/issues/27812> for more information

error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?
  --> src/descriptor/mod.rs:61:19
   |
61 | pub type KeyMap = HashMap<DescriptorPublicKey, DescriptorSecretKey>;
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27812 <https://github.com/rust-lang/rust/issues/27812> for more information

...

This could be solved by either making the serde feature set std and offering an equivalent serde-nostd feature, or, by at least sufficiently documenting that choosing either is required and doing otherwise might lead to unexpected behavior. Happy to open a PR to address this in one way or the other.

[apoelstra]

Right now there is a comment in Cargo.toml saying that at least one of std, no-std is required. We would definitely welcome an improvement to this documentation! For example AFAICT it does not appear in the README. We should also detect this case and issue an explicit compiler error giving the user more information.

We also periodically re-assess whether this confusing no-std feature stilll needs to exist at all. I believe we need it because the core2 crate is implied by it, we you can't make dependencies be implied by the absense of std. But maybe we ought to rename the feature to alloc or core2 or something ... and maybe we still ought to make it optional.

[apoelstra]

Oh, lol! I thought this was rust-bitcoin. Here in rust-miniscript we don't even have the Cargo.toml comment :). We should definitely fix that.

In our case, the no-std feature is needed to turn on the same feature in rust-bitcoin and to add the hashbrown dep (neither of which we can do without a feature flag of our own).

[tnull]

Closing this as it was addressed in #534 / rust-bitcoin/rust-bitcoin#1711. :)