chore(deps): pull portable-atomic only where it is reachable - #18
Merged
Conversation
A firmware was fetching and compiling `portable-atomic` and then discarding it at link time. Its only use site is gated `all(not(target_has_atomic = "64"), feature = "std")` -- a `no_std` build uses `options::split64` instead -- but the dependency was declared for the target regardless of the feature. It is now `optional` and enabled by `std`, so it appears exactly where it is used. Verified on three shapes: riscv32imac WITH std 1 in the graph (the case that needs it) riscv32imac no_std 0 (was 1, and 20 build artifacts) x86_64 windows 0 (target section never matches) Costs nothing on the device either way -- after `split64` landed, its symbols in a shipped ESP32 image went to zero and its 4,288-byte `LOCKS` table left the symbol map -- so this buys an accurate dependency graph rather than bytes. An unused crate still shows up in an SBOM, a `cargo audit`, and every dependency count a firmware reviewer looks at. No version bump here: this rides with the next release rather than spending a 2.0.1 on tidiness. Gates: 109/33 default, 90/19 small profile, clippy on three configs, both RISC-V targets at both geometries, rusty_alloc-api no_std, wasm32, unsafe census, gate selftest 5/5, wasm size ratchet. Downstream corpus unchanged -- spacedb-sdk (plain and secure), rusty_alloc_default and rusty_zstd all green; rusty_maplibre still on its documented `features = ["std"]` migration. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A firmware was fetching and compiling
portable-atomicand then discarding it at link time.Its only use site is gated
all(not(target_has_atomic = "64"), feature = "std")— ano_stdbuild usesoptions::split64instead — but the dependency was declared for the target regardless of the feature. It is nowoptionaland enabled bystd.riscv32imacwithstdriscv32imacno_stdx86_64-pc-windows-msvcThis buys an accurate dependency graph, not bytes. It already cost nothing on the device: after
split64landed,portable_atomicsymbols in a shipped ESP32 image went to zero and its 4,288-byteLOCKStable left the symbol map. But an unused crate still shows up in an SBOM, acargo audit, and every dependency count a firmware reviewer looks at.No version bump — this rides with the next release rather than spending a 2.0.1 on tidiness.
Gates: 109/33 default, 90/19 small profile, clippy on three configs, both RISC-V targets at both geometries,
rusty_alloc-apino_std, wasm32, unsafe census, gate selftest 5/5, wasm size ratchet. Downstream corpus unchanged.🤖 Generated with Claude Code