feat: enable `no_std` compilation and check it in CI by JoseSK999 · Pull Request #93 · mit-dci/rustreexo

JoseSK999 · 2026-02-05T01:42:55Z

Description

This PR adds two new dependencies that are needed for no_std support: hashbrown (HashMap alternative) and bitcoin_io (io trait and type replacements).

The AccumulatorHash trait bounds depend on whether we use std or no_std now.

Note

This seems to work but perhaps we should add a feature powerset CI check to ensure all 4 combinations work fine for clippy and testing.

The prelude list is from floresta-common, I think I can trim a couple of these imports.

src/lib.rs

Davidson-Souza · 2026-02-05T15:18:12Z

Cargo.toml

+bitcoin_hashes = { version = "0.19", default-features = false }
+hex-conservative = { version = "1.0.0", default-features = false }
 serde = { version = "1.0", features = ["derive"], optional = true }
+hashbrown = "0.16.1"


Just to make sure: you can't disable a dependency if a feature is on, right? You can only enable them. Because now we have at least one non rust-bitcoin dependency that's not feature-gated. I guess it's ok, since hashbrown is super small and is the basis for std's hashmap implementation

Yes, sort of ugly. Otherwise we would have to create a no-std or hashbrown feature required for no-std.

But as you say, std::collections::HashMap is wrapping the hashbrown one: https://doc.rust-lang.org/src/std/collections/hash/map.rs.html

src/accumulator/mem_forest.rs

src/accumulator/node_hash.rs

src/accumulator/pollard.rs

src/accumulator/proof.rs

JoseSK999 · 2026-02-05T18:31:48Z

Pushed 21ae740

Cleanup the prelude mod, now it's mostly exporting alloc items to mirror the std prelude, io and HashMap/HashSet
Imported some items

And very important:

Test and check rustreexo without the std feature (this catched doctest issues and a panic in tests)

luisschwab · 2026-02-05T18:49:54Z

@JoseSK999 you could also add a test-no-std recipe to the justfile and have CI run the recipe, so we can avoid duplication and have the justfile as the single source of truth for testing.

JoseSK999 · 2026-02-05T19:13:56Z

@JoseSK999 you could also add a test-no-std recipe to the justfile and have CI run the recipe, so we can avoid duplication and have the justfile as the single source of truth for testing.

I had extended the just test recipe to test no default features (i.e., no-std), I think better than a separate just test-no-std. But CI is not using just test. Should I make the recipe be

test:
    cargo +nightly test --no-default-features
    cargo +nightly test --all-features
    cargo +stable test --no-default-features
    cargo +stable test --all-features

and use it in CI? (not sure)

luisschwab · 2026-02-05T19:22:07Z

Oh, I thought I had changed CI to use the justfile's recipes. I think that is a better approach (I do it on my own repos). Thoughts @Davidson-Souza

JoseSK999 · 2026-02-05T19:26:10Z

CI here uses just check and just test-msrv, but not just test

luisschwab · 2026-02-05T19:30:06Z

I guess that just test and just test-msrv should be extended to check for no-std and have CI use those instead.

JoseSK999 · 2026-02-06T04:32:18Z

So I have made just test delegate to just test-stable and just test-nightly. In CI we now call these two 👺

just test-{stable/nightly/msrv} and just check are all now running with --no-default-features too

Davidson-Souza · 2026-02-12T17:36:49Z

src/accumulator/pollard.rs

+//! Nodes are kept in memory, and they hold their hashes, a reference to their **aunt** (not
+//! parent!), and their nieces (not children!). We do this to allow for proof generation, while
+//! prunning as much as possible. In a merkle proof, we only need the sibling of the path to the
+//! root, the parent is always computed on the fly as we walk up the tree. Some there's no need to


Suggested change

//! root, the parent is always computed on the fly as we walk up the tree. Some there's no need to

//! root, the parent is always computed on the fly as we walk up the tree. So, there's no need to

This commit adds two new dependencies that are needed for `no_std` support: `hashbrown` (`HashMap` alternative) and `bitcoin_io` (`io` trait and type replacements). The `AccumulatorHash` trait bounds depend on whether we use `std` or `no_std` now.

This ensures skipping the `std` feature works as expected even though some traits and types are from `hashbrown` and `bitcoin_io`. Also runs doctests and clippy. Created `test-stable` and `test-nightly` recipes for use in CI.

Davidson-Souza

ACK 4bd5934

luisschwab · 2026-02-13T16:45:00Z

src/lib.rs

+extern crate alloc;
+
+#[cfg(not(feature = "std"))]
+/// Re-exports `alloc`/`std` basics plus HashMap/HashSet and IO traits.


Suggested change

/// Re-exports `alloc`/`std` basics plus HashMap/HashSet and IO traits.

/// Re-exports `alloc` basics plus HashMap/HashSet and IO traits.

luisschwab · 2026-02-13T16:49:09Z

justfile

@@ -33,7 +48,7 @@ test-msrv:
    cargo update -p serde_json --precise 1.0.81
    cargo update -p serde --precise 1.0.160
    cargo update -p half --precise 2.4.1
-
+
+    cargo +1.74.0 test --no-default-features
    cargo +1.74.0 test --all-features
    rm Cargo.lock


nit: you could add a ci/pin-msrv.sh script to pin dependencies and have the justfile and CI run it so we have a single source of truth (see https://github.com/bitcoindevkit/bdk/blob/master/ci/pin-msrv.sh and https://github.com/bitcoindevkit/bdk/blob/master/.github/workflows/cont_integration.yml#L45-L47)

@JoseSK999 you could also add a section to the README about building with MSRV:

Minimum Supported Rust Version

This library should compile with any combination of features with Rust 1.74.0.

To build with the MSRV you will need to pin dependencies:

bash ci/pin-msrv.sh

JoseSK999 mentioned this pull request Feb 5, 2026

ci: add no-std job to check floresta-common getfloresta/Floresta#825

Merged

Davidson-Souza requested changes Feb 5, 2026

View reviewed changes

JoseSK999 force-pushed the feat-enable-no-std branch from 606db6e to 21ae740 Compare February 5, 2026 18:23

JoseSK999 force-pushed the feat-enable-no-std branch from 21ae740 to 8101330 Compare February 6, 2026 04:29

Davidson-Souza requested changes Feb 12, 2026

View reviewed changes

JoseSK999 force-pushed the feat-enable-no-std branch from 8101330 to a03cc61 Compare February 13, 2026 11:53

JoseSK999 added 3 commits February 13, 2026 12:55

feat: enable no_std compilation

1e77b5d

This commit adds two new dependencies that are needed for `no_std` support: `hashbrown` (`HashMap` alternative) and `bitcoin_io` (`io` trait and type replacements). The `AccumulatorHash` trait bounds depend on whether we use `std` or `no_std` now.

ci: test no_std with a bare-metal compilation

0baf096

ci: test and check no-default-features

4bd5934

This ensures skipping the `std` feature works as expected even though some traits and types are from `hashbrown` and `bitcoin_io`. Also runs doctests and clippy. Created `test-stable` and `test-nightly` recipes for use in CI.

JoseSK999 force-pushed the feat-enable-no-std branch from a03cc61 to 4bd5934 Compare February 13, 2026 11:55

Davidson-Souza approved these changes Feb 13, 2026

View reviewed changes

luisschwab suggested changes Feb 13, 2026

View reviewed changes

	//! root, the parent is always computed on the fly as we walk up the tree. Some there's no need to
	//! root, the parent is always computed on the fly as we walk up the tree. So, there's no need to

	/// Re-exports `alloc`/`std` basics plus HashMap/HashSet and IO traits.
	/// Re-exports `alloc` basics plus HashMap/HashSet and IO traits.

Conversation

JoseSK999 commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Note

Uh oh!

Uh oh!

Davidson-Souza Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

JoseSK999 Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

JoseSK999 commented Feb 5, 2026

Uh oh!

luisschwab commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JoseSK999 commented Feb 5, 2026

Uh oh!

luisschwab commented Feb 5, 2026

Uh oh!

JoseSK999 commented Feb 5, 2026

Uh oh!

luisschwab commented Feb 5, 2026

Uh oh!

JoseSK999 commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Davidson-Souza Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

JoseSK999 Feb 13, 2026

Choose a reason for hiding this comment

Uh oh!

Davidson-Souza left a comment

Choose a reason for hiding this comment

Uh oh!

luisschwab Feb 13, 2026

Choose a reason for hiding this comment

Uh oh!

luisschwab Feb 13, 2026

Choose a reason for hiding this comment

Uh oh!

luisschwab Feb 13, 2026

Choose a reason for hiding this comment

Minimum Supported Rust Version

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

JoseSK999 commented Feb 5, 2026 •

edited

Loading

luisschwab commented Feb 5, 2026 •

edited

Loading

JoseSK999 commented Feb 6, 2026 •

edited

Loading