build(deps): drop three dependency features nothing activates - #1201
Conversation
A second sweep over the manifests after the round-1 cuts. No crate leaves the graph this time; these are features being compiled for no caller: - futures' `thread-pool` in wacore's dev-dependencies. `ThreadPool` appears nowhere in the crate's tests, benches or examples. Costs no package (futures 0.3.33 dropped num_cpus for available_parallelism), only the module's compile time. - syn's `parsing` in the root dev-dependencies. It is already in syn 3.0's default set and default-features was never disabled, so the entry only restated what was on. `full` is not default and stays. - wacore-binary's `serde` in wacore-appstate. appstate builds and tests clean without it; wacore needs it and still declares it, so a workspace build resolves the same feature set either way. The difference is for anyone depending on wacore-appstate alone, who no longer pulls serde derives for every node type plus smallvec/serde. Verified by removal rather than by reading: each was taken out and the workspace rebuilt. That order matters here, because feature unification makes a single-crate `cargo check` lie. Dropping `wacore-binary/serde` from wacore first appeared to work, and only failed once appstate's copy came out too, since appstate had been enabling it for wacore all along.
|
Warning Review limit reached
Next review available in: 36 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI (base), Organization UI (inherited) Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
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 |
📦 Binary size report
.text per crate
Baseline: |
2 participants
Summary
Second sweep over the dependency surface after #1200. The headline is that there is not much left: no crate leaves the graph,
Cargo.lockis unchanged, and the three changes here are features being compiled with no caller. The audit trail below is the more useful half of this PR — it records what was checked and found load-bearing, so the same ground does not get re-covered.Changes
futures'thread-pool, wacore dev-dependencies.ThreadPoolappears nowhere in the crate's tests, benches or examples. Costs no package (futures 0.3.33 replacednum_cpuswithavailable_parallelism), only the module's compile time.syn'sparsing, root dev-dependencies. Already in syn 3.0's default set, anddefault-featureswas never disabled, so the entry restated what was on.fullis not default and stays.wacore-binary'sserde, inwacore-appstate. appstate builds and tests clean without it.wacoredoes need it and still declares it, so a workspace build resolves the same feature set either way; the difference is for anyone depending onwacore-appstatealone, who no longer pulls serde derives for every node type plussmallvec/serde.Method
Each candidate was removed and rebuilt, not just read. That order matters more than it sounds: feature unification makes a single-crate
cargo checklie. Droppingwacore-binary/serdefromwacoreappeared to work —cargo check -p wacore --libpassed clean — and only failed once appstate's copy came out too, because appstate had been enabling the feature on wacore's behalf the whole time. The conclusion flipped from "wacore doesn't need serde" to "appstate doesn't need serde" on that second build.Audit trail: checked, found load-bearing
Recording these so the next pass can skip them.
No unused dependencies remain. A cross-check of every
[dependencies],[dev-dependencies]and[build-dependencies]entry in all 14 manifests against actual source references found zero orphans. Four flagged by the naive scan are legitimate:dhatandgetrandomin wacore are feature-only (dhat-heap,js),serde_reprin waproto is referenced from generated code viacfg_attrinbuild.rs, andlibsqlite3-sysis an optional pin.Features that looked droppable but are not:
curve25519-dalek/x25519-dalekprecomputed-tablesED25519_BASEPOINT_TABLEis used directly incore/curve/curve25519.rsfor XEdDSA signing. The constant only exists with the feature.cbc'sblock-padding(via defaults)Pkcs7is used in production crypto incrypto/provider.rs.tracing'sattributestracing::instrumentis used acrossusync.rs,download.rsand others.yoke'sderivederive(Yokeable)is used innode.rsandjid.rs.zerocopy'sderiveFromBytes/KnownLayout/Immutable/Unalignedderives invoip/rtp.rsandvoip/stun.rs.chrono'sserdein wacorechrono::serde::ts_secondson event and message timestamps.rand'sstd_rng/thread_rngStdRngandrand::rng()are both used, including outside tests.smallvec'sserdewacore-binary's ownserdefeature for node attrs, not by accident.futuresfacade →futures-utilchannel::oneshot,executor::block_on,task::ArcWake, theselect!/join!macros, andstream. Narrowing would mean four separate deps, not one.async-trait#[async_trait]sites against 551dynuses. Native async-in-trait is not dyn-safe, so this is structural, not vestigial.webrtc-*cratesvoip/transport.rs, including the deliberate dualwebrtc-utilmajors already documented indeny.toml.Duplicate versions are not actionable from here. The 42 duplicated packages are almost entirely the webrtc tree lagging a RustCrypto generation behind (optional, off by default) and are already enumerated with rationale in
deny.toml. The two that show up in a default build were traced to their parents:getrandom 0.2.17comes fromring,hashbrown 0.15.5frombuffa— both upstream pins with no manifest-side lever.No functional overlap to collapse. The default build carries three UTF-8 crates (
simdutf8,utf8-zero,smoothutf8); they arrive fromtokio-websockets,ureq, and our ownwacorerespectively, so no one of them can substitute for another.Cost
Cargo.lockunchanged, 462 packages before and after, and the size job confirms zero codegen change: llvm-lines are flat to the line in all four metrics (wacore511,608 both sides; root lib 727,450 both sides; both copy counts unchanged).The reported binary numbers move by +832 B stripped (+0.01%). That is link-layout noise, not this diff: nothing here changes what is compiled into a build that includes
wacore, two of the three trims are dev-only, and flat llvm-lines mean no instruction was added or removed. For calibration, #1200's size delta swung from +192 B to −1.56 KiB across two commits whose codegen barely differed, so ±1 KiB on this gate is below its own resolution.The real gain is compile time and a smaller standalone footprint for
wacore-appstate.Validation
All green, 1900+ tests.
whatsapp-rust-voip-cliis excluded because itscpaltoalsa-syschain needs ALSA headers this environment lacks; it was not touched.Semver Checks (informational)is red and is not this PR's: the same 63 findings appear onmain, allwaproto::whatsapp::*generated protobuf types drifting from the published 0.6.0 baseline, none namingwacoreorwacore-binary. See the comment thread for the base-branch evidence.