feat: add cargo-unused-deps

[martin-kolinek]

WhatAdds cargo-unused-deps: a cargo subcommand that fails when a [workspace.dependencies] entry is inherited by no workspace member, plus its design doc.- docs/design/README.md — the design.- src/ — detection, --fix, allow-list. Integration tests cover Cargo-resolved membership, every inheritance form, the allow-list and its stale entries, --fix comment carrying and dropping, and the error paths; 100% line and function coverage.Work item: 7790070.## Whycargo udeps resolves the crate graph and asks which declared dependencies go unused. A [workspace.dependencies] entry that no member inherits never enters that graph, so it is invisible to udeps — and to cargo machete, for the same structural reason.That blind spot accumulated 48 stale entries in this repo before #99 swept them out by hand, with udeps green throughout. Per review feedback on #99, the check belongs in cargo-anvil so every repo using it benefits, rather than living as a one-off script.## The ruleAn entry is unused when no workspace member declares it with workspace = true — across dependencies, dev-dependencies, build-dependencies and their [target.'cfg(…)'] forms, in both the inline and dotted spellings.Manifest-only, so the gate has no false positives and needs no compilation, toolchain pin, or network. It slots into the modified tier next to ensure-no-cyclic-deps and ensure-no-default-features, and composes with udeps without overlap:| Question | Answered by ||---|---|| Is this catalog entry inherited by any member? | this tool || Is an inherited dependency actually referenced in code? | udeps |## Prior art evaluated- cargo-shear does implement a shear/unused_workspace_dependency diagnostic, and it does catch the case — verified by injecting an unused entry into this repo's root manifest. But it derives the verdict from static source-usage analysis, so it inherits that analysis's macro-expansion blind spots: it reports 8 entries here (rustdoc-types-v50..v57) that are inherited and genuinely used, via generate_version_support!("50", rustdoc_types_v50). It also skips the check entirely for single-member workspaces. Its other diagnostics remain independently interesting — separate decision.- cargo-unused-workspace-deps on crates.io does exactly this, but is one release from Sept 2025 with no commits since — not something to pin as an anvil dependency.## Points to review1. --fix is in scope, unlike the sibling ensure-no-default-features ("the tool reports; the human edits"). Rationale: removing an entry nobody inherits is mechanical and lossless — Cargo.lock is unaffected by construction — unlike deciding which features to keep. The comment-carrying rules are specified normatively, including the empty-table case.2. Members come from cargo metadata --no-deps rather than re-deriving members/globs/exclude textually. Costs a subprocess, but any disagreement with Cargo that drops a member is a false positive.3. Allowlist lives in [workspace.metadata.…] allowed = […], not a CLI flag, because the generated recipe invokes the tool with a fixed argument list.## Not in this PRThe anvil wiring (versions.just pin, tools.just install/validate, checks/ recipe, pr-fast group, checks.md catalog row). Anvil installs pinned tools from crates.io, so the wiring has nothing to pin until the crate's first release; design §7 says so explicitly._{🤖 Authored by Clawpilot (an AI agent), not by a human.}

[Codecov Comments Bot (codecov-commenter)]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.5%. Comparing base (26e5c60) to head (3431f90).
⚠️ Report is 5 commits behind head on main.

❌ Your project status has failed because the head coverage (97.5%) is below the target coverage (100.0%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@          Coverage Diff           @@
##            main    #102    +/-   ##
======================================
  Coverage   97.5%   97.5%            
======================================
  Files        300     304     +4     
  Lines      68538   68862   +324     
======================================
+ Hits       66876   67197   +321     
- Misses      1662    1665     +3     

Flag	Coverage Δ
linux	97.5% <100.0%> (+<0.1%)	⬆️
linux-arm	97.5% <100.0%> (+<0.1%)	⬆️
scheduled	?
windows	97.7% <100.0%> (+<0.1%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[martin-kolinek]

🤖 Clawpilot here! Posted automatically by Clawpilot (an AI agent), not by a human. Please verify before acting.

Agreed, and changed — the missing-[workspace] case now succeeds instead of erroring.

Your reasoning is the deciding one: the generated anvil recipe runs the same command in every repo it manages, including single-crate ones. A hard error there would fail exactly the repositories that never had the problem, and each would need a local opt-out to get back to green. Succeeding is also the honest answer — "no catalog entry goes uninherited" holds vacuously when there is no catalog.

Implemented as you suggested, with the switch inverted so the lenient reading is the default:

$ cargo ensure-no-unused-workspace-deps                        # single-crate repo
ℹ️ Cargo.toml has no [workspace] table; there is no dependency catalog to check.   # exit 0

$ cargo ensure-no-unused-workspace-deps --require-workspace
❌ Cargo.toml has no [workspace] table.                                            # exit 1

--require-workspace keeps the original strict behaviour for callers that know they are pointing at a workspace root and want a misdirected --manifest-path to fail rather than pass quietly. Both paths are covered by tests (a_manifest_without_a_workspace_table_passes_with_a_note, require_workspace_rejects_a_manifest_without_a_workspace_table), and the design doc's exit-code section and a new "Manifests that are not workspace roots" section record the rationale.

The rest of the crate is implemented in the same push (4d7b097) — detection, --fix, allow-list, 18 integration tests, 100% line and function coverage. Verified end to end against this repo: all 70 catalog entries report as inherited, an injected entry is flagged, and --fix removes it and restores the manifest byte for byte.

Leaving this thread unresolved for you to close.

[github-actions]

⚠️ Breaking Changes Detected

error: failed to retrieve local crate data from git revision

Caused by:
    0: failed to retrieve manifest file from git revision source
    1: possibly due to errors: [
         failed to parse /home/runner/work/ox-tools/ox-tools/target/semver-checks/git-origin_main/f3db67486d159c2faf7ea3788a63c4b0eb93822d/crates/cargo-aprz-lib/tests/fixtures/tiny-virtual-workspace/Cargo.toml: no `package` table,
         failed to parse /home/runner/work/ox-tools/ox-tools/target/semver-checks/git-origin_main/f3db67486d159c2faf7ea3788a63c4b0eb93822d/Cargo.toml: no `package` table,
         failed to parse /home/runner/work/ox-tools/ox-tools/target/semver-checks/git-origin_main/f3db67486d159c2faf7ea3788a63c4b0eb93822d/crates/cargo-anvil/tests/fixtures/customized/Cargo.toml: no `package` table,
         failed to parse /home/runner/work/ox-tools/ox-tools/target/semver-checks/git-origin_main/f3db67486d159c2faf7ea3788a63c4b0eb93822d/crates/cargo_ensure_no_cyclic_deps/tests/fixtures/with_dev_cycle/Cargo.toml: no `package` table,
         failed to parse /home/runner/work/ox-tools/ox-tools/target/semver-checks/git-origin_main/f3db67486d159c2faf7ea3788a63c4b0eb93822d/crates/cargo_ensure_no_cyclic_deps/tests/fixtures/without_cycle/Cargo.toml: no `package` table,
         failed to parse /home/runner/work/ox-tools/ox-tools/target/semver-checks/git-origin_main/f3db67486d159c2faf7ea3788a63c4b0eb93822d/crates/cargo_ensure_no_cyclic_deps/tests/fixtures/with_self_dev_dep/Cargo.toml: no `package` table,
         failed to parse /home/runner/work/ox-tools/ox-tools/target/semver-checks/git-origin_main/f3db67486d159c2faf7ea3788a63c4b0eb93822d/crates/cargo-anvil/tests/fixtures/opt-outs/Cargo.toml: no `package` table,
         failed to parse /home/runner/work/ox-tools/ox-tools/target/semver-checks/git-origin_main/f3db67486d159c2faf7ea3788a63c4b0eb93822d/crates/cargo-anvil/tests/fixtures/migration/Cargo.toml: no `package` table,
         failed to parse /home/runner/work/ox-tools/ox-tools/target/semver-checks/git-origin_main/f3db67486d159c2faf7ea3788a63c4b0eb93822d/crates/cargo_ensure_no_cyclic_deps/tests/fixtures/with_cycle/Cargo.toml: no `package` table,
       ]
    2: package `cargo-ensure-no-unused-workspace-deps` not found in /home/runner/work/ox-tools/ox-tools/target/semver-checks/git-origin_main/f3db67486d159c2faf7ea3788a63c4b0eb93822d

Stack backtrace:
   0: <anyhow::Error>::msg::<alloc::string::String>
   1: <cargo_semver_checks::rustdoc_gen::RustdocFromProjectRoot>::get_crate_source
   2: <cargo_semver_checks::rustdoc_gen::StatefulRustdocGenerator<cargo_semver_checks::rustdoc_gen::CoupledState>>::prepare_generator
   3: <cargo_semver_checks::Check>::check_release::{closure#5}
   4: <cargo_semver_checks::Check>::check_release
   5: cargo_semver_checks::exit_on_error::<cargo_semver_checks::Report, cargo_semver_checks::main::{closure#5}>
   6: cargo_semver_checks::main
   7: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
   8: main
   9: <unknown>
  10: __libc_start_main
  11: _start

If the breaking changes are intentional then everything is fine - this message is merely informative.

Remember to apply a version number bump with the correct severity when publishing a version with breaking changes (1.x.x -> 2.x.x or 0.1.x -> 0.2.x).

[Copilot]

Pull request overview

Copilot reviewed 14 out of 15 changed files in this pull request and generated no new comments.

Suppressed comments (3)

Previously missed (1) — in code that hasn't changed since the last review.

crates/cargo-ensure-no-unused-workspace-deps/src/fix.rs:16

• Outcome::carries includes both comment blocks that are successfully carried onto a survivor and comment blocks that are ultimately dropped (onto: None). The current field doc says "moved", which is misleading given the Dropped ... reporting and Carry::onto semantics.

This issue also appears in the following locations of the same file:

• line 20
• line 36

    /// Comment blocks that moved off a removed entry.

crates/cargo-ensure-no-unused-workspace-deps/src/fix.rs:23

• Carry records both successful carries and drops (onto: None), so the doc comment "Only recorded when comments actually moved" is incorrect. It’s still true that from is never empty, but the condition is that at least one comment line existed on removed entries (carried or dropped).

/// Comments that belonged to removed entries and had to go somewhere else.
///
/// Only recorded when comments actually moved, so `from` is never empty.
///

crates/cargo-ensure-no-unused-workspace-deps/src/fix.rs:36

• Carry::lines is also used when comments are dropped (onto: None), so describing them as lines that "moved" is inaccurate.

    /// How many comment lines moved.

[Martin Taillefer (geeknoid)]

martin-kolinek Would it be worth expanding the scope of this tool to completely replace cargo-udeps? So simultaneously check whether each project has superfluous dependencies, and then whether the workspace has superfluous dependencies?

[martin-kolinek]

Martin Taillefer (@geeknoid), I'm not a huge fan of reimplementing existing tools unless we can fix specific issues with those tools - do we have issues with cargo-udeps? I thought we're pretty happy with how it works.

[Sander Saares (sandersaares)]

[Copilot speaking]

Published 29 findings. One finding follows up on an existing discussion thread.

See diagnostics

Diagnostic	Value
Cache	Hit

[Copilot]

🟡 Changes recommended

The tool’s description currently overpromises scope and the allow-list parsing silently ignores invalid config values, which can lead to confusing behavior for users.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 14/15 changed files
• Comments generated: 3
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

The new crate’s documentation overstates --fix concurrency guarantees and the allow-list parsing silently ignores malformed entries, which should be addressed for correct user-facing behavior.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (1)

crates/cargo-unused-deps/src/detect.rs:74

• allowed = [...] parsing silently drops any non-string entries via filter_map(Value::as_str). A typo like allowed = [123] would be ignored without warning, causing confusing CI behavior (the allow-list appears configured, but nothing is allowed). Consider validating that every entry is a string and returning a clear error when the config is malformed (similar to other manifest parsing in this repo, e.g. cargo-anvil’s [workspace].members parsing errors on non-string entries in crates/cargo-anvil/src/workspace.rs:129-141).

        .and_then(|config| config.get("allowed"))
        .and_then(Item::as_array)
        .map(|names| names.iter().filter_map(Value::as_str).map(ToOwned::to_owned).collect())
        .unwrap_or_default();

• Files reviewed: 14/16 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

The allow-list parser silently ignores a present-but-wrong-type allowed value instead of reporting a configuration error, which can cause unexpected behavior in CI.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 14/16 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

The implementation, documentation, and integration tests align on the stated rule/edge cases and no concrete correctness or contract issues were found in the reviewed diffs.

Review details

• Files reviewed: 14/16 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

The implementation, tests, and design doc appear consistent; only a minor error-context wording improvement was identified.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

crates/cargo-unused-deps/src/lib.rs:300

• The error context for creating the temp file is currently failed to write <manifest>, which is misleading when the failure is actually "could not create a temp file" (e.g., permissions / read-only directory). Using a creation-specific context here makes the failure clearer and easier to act on.

• Files reviewed: 14/16 changed files
• Comments generated: 0 new
• Review effort level: Lite