Repository navigation
refactor!: harmonize workspace crates behind hex-conservative 1.x - #1115
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (8)
🚧 Files skipped from review as they are similar to previous changes (2)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe workspace replaces ChangesHexadecimal conversion migration
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~25 minutes Change: Other Merge Risk: ⚪ Minimal · up to The reviewed migration preserves the identified length checks, byte ordering, and RPC JSON hex format. No actionable merge-blocking regression is established; malformed-input compatibility remains unverified. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 76.26% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 139 functions across 53 files. (4 skipped: 4 unsupported.)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Waiting for bot review — coderabbitai not yet. Wait for the missing reviews, or a writer can post |
|
Bots are done — your move: post |
|
/self-reviewed |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## dev #1115 +/- ##
==========================================
- Coverage 77.96% 77.92% -0.05%
==========================================
Files 302 302
Lines 79049 79108 +59
==========================================
+ Hits 61634 61647 +13
- Misses 17415 17461 +46
|
|
Ready for review — files with no dedicated owner: QuantumExplorer or ZocoLini or xdustinface · |
|
This PR has merge conflicts with the base branch. Please rebase or merge the base branch into your branch to resolve them. |
|
Bots are done — your move: post |
|
/self-reviewed |
|
Ready for review — files with no dedicated owner: QuantumExplorer or ZocoLini or xdustinface · |
ZocoLini
left a comment
There was a problem hiding this comment.
One thing I'd change: I don't think hex belongs in dashcore_hashes. Re-exporting it
there comes from bitcoin_hashes, which needs hex for its own Display/FromStr, but in
our code hex is a general utility (RPC JSON, FFI, wallet, tests) with nothing to do
with hashing. Pointing dashcore_hashes::hex at hex-conservative 1.x keeps that
coupling in place.
Proposal: a small dedicated crate, e.g. dashcore-hex that:
- re-exports hex_conservative::*
- adds a serde module for Vec/[u8; N] (the serde_hex helper from #1115 moves
here, since 1.x dropped the upstream one) - replaces internals::hex, so we end up with exactly one hex module in the workspace
Workspace crates would depend on it directly, and dashcore_hashes would stop exposing
hex. For parsing hash types we keep using FromStr/.parse(), which doesn't need our
crate.
Optionally, dashcore could also re-export it as dashcore::hex, like bitcoin::hex, for
downstream convenience. I'd lean towards not doing that and having consumers depend
on dashcore-hex explicitly, but I'm fine either way.
Do you think you can do this here or you rather prefer to do it in #1110 or in a different PR??
Motivation
The Rust ecosystem provides a plethora of hex encoding crates, each of them with different APIs, encoding/decoding behaviours and semantics.
hex-conservative, the crate published byrust-bitcoinis one of them but it only one of many. The problem with using these crates interchangeably is that differences in semantics can result in parsing bugs due to mismatched assumptions and invariants between crates.Furthermore, portions of
rust-dashcorealready have inline parsing routines mixed with ownership of a hex module indashcore-internaland some unusedserdeutility macros on top of using two different dependencies,hexandhex_litin different workspace crates.While rust-dashcore#1108 does forward theSee rust-dashcore#1110.hexmodule frombitcoin-hashes0.14, that in effect propagateshex-conservative0.2 throughout the codebase. To front load the effort of having to migrate to hex-conservative 1.x through rust-bitcoin#5710 and rust-bitcoin#6148, this pull request also replaces the export frombitcoin-hasheswithhex-conservative1.x.Additional Information
Depends on refactor!: consolidate common definitions to workspace
Cargo.toml, bumpbase58ckto 0.5.0, pass through definitions frombitcoin-{hashes,internals,crypto}anddash-pkc#1108Dependency for refactor!: drop
dashcore_hashes::hexin favour ofhex-conservative, banhex{,_lit,-literal}withcargo deny#1110This pull request was originally the first half of rust-dashcore#1110 but was split into two as a workaround for CodeRabbit's 100 files changed upper limit.
PR Hygiene ·
a4be8acCHANGELOG.md,Cargo.toml,crypto/Cargo.tomland 35 more) — QuantumExplorer or ZocoLini or xdustinfacedash-spv(dash-spv/Cargo.toml,dash-spv/src/chain/chain_work.rs,dash-spv/src/chain/checkpoints.rsand 3 more) — QuantumExplorer or ZocoLini or xdustinfacekey-wallet-manager(key-wallet-manager/Cargo.toml,key-wallet-manager/examples/wallet_creation.rs,key-wallet-manager/tests/test_serialized_wallets.rs) — QuantumExplorer or ZocoLini or xdustinfacekey-wallet(key-wallet/Cargo.toml,key-wallet/README.md,key-wallet/examples/basic_usage.rsand 13 more) — QuantumExplorer or ZocoLini or xdustinfaceWhen every merge requirement is met, the
PR Hygienecheck passes. Reviewer limits do not block merging; other required GitHub checks and protections still apply.