Exclude optional dependencies that no enabled feature activates

[nissessenap]

Exclude optional dependencies that no enabled feature activates

Fixes #766.

The problem

cargo metadata lists optional dependencies in resolve.nodes[].deps whether or not
the resolver enabled them. generator.rs never read the feature information that comes
back alongside them, so every optional dependency of every crate in the graph ended up
in the SBOM — along with everything reachable only through it.

Concretely, a crate whose only dependency is serde_with 3 gets an SBOM with 41
components. cargo tree -e normal,build reports 13.

This is also what makes the README's claim to "honor a particular combination of enabled
Cargo features" true rather than aspirational.

The fix

The resolve graph is pruned once, up front, by replaying the feature resolution
cargo metadata already recorded and dropping the edges it shows were never taken:

• resolve.nodes[].features gives the features the resolver enabled on each package.
• packages[].features expands those into the set of activated dependencies, following
  dep:foo, foo/bar (activating), foo?/bar (weak, not activating), and plain feature
  names recursively.
• Each NodeDep is matched back to the [dependencies] entries that could have produced
  it — by package name, kind and target platform — and survives if any of them is
  non-optional or activated. Renamed dependencies are keyed on the rename (chrono_0_4),
  since that is what feature syntax refers to.

Because this happens before any workspace member is processed, the rest of the generator
is untouched: filtered_dependencies(), all_dependencies() and index_dep_kinds() see
a resolve graph that no longer contains the edges, so components disappear along with them
and an edge that is never built cannot raise a component's scope.

Every lookup fails open — an edge whose manifest entry cannot be identified is kept, so
the change can remove false positives but not introduce false negatives.

Measured

Against cargo tree -e normal,build --no-dedupe on the resolved graph:

crate under test	before	after	cargo tree
serde_with 3	41	13	13
reqwest 0.12 (json, rustls-tls)	125	109	109
sqlx 0.8 (sqlite only)	108	101	101
rustls 0.23	22	19	19
reqwest --target x86_64-pc-windows-msvc	123	107	107
reqwest --target wasm32-unknown-unknown	62	62	62
tokio 1 (full), axum 0.8, clap 4 (derive)	unchanged	unchanged	matches
polars 0.51 (lazy)	273	262	256
image 0.25	102	102	95

Zero false negatives anywhere: nothing cargo tree reports is missing from the patched
output. No measurable runtime cost (0.28s either way on the 273-component polars graph).

What this does not fix

• Workspace feature unification (rust-lang/cargo#7754). cargo metadata resolves
  features across the whole workspace, so a member inherits the union of its siblings'
  features. The polars residual above is this: cargo metadata genuinely reports
  hex as enabled on polars-ops, and an edge filter has to believe it.
• The --target flag does not seem to respect target-conditional features in generated SBOM. #871, target-conditional features. A crate with cfg(musl)/cfg(not(musl)) feature
  splits reports both branches in node.features, with or without --filter-platform.
  The image residual above is the related platform case (wasm-bindgen on a host build).

Both are upstream in Cargo, and neither is made worse by this change.

Tests

• Unit tests for the feature expansion: dep:, implicit features, transitive expansion,
  foo/bar vs foo?/bar, renames, cyclic features, unknown features.
• A new tests/fixtures/optional_deps workspace covering a non-optional dependency, one
  activated by dep:, one activated only through its rename, one named only weakly, and
  one never named at all. It fails against main.
• weak_dep owns a private dependency, so pruning it cascades, and the same test asserts
  the pruned graph leaves no dangling dependencies references.

---

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 53 complexity · 4 duplication

Metric	Results
Complexity	53
Duplication	4

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}