Report unused `[dependencies]`

[epage]

What it does

Detect unused dependencies and suggest removing them

Advantage

• Faster builds
• False positives if done in rustc

Drawbacks

• Complicated

Example

[package]
name = "libc"

[dependencies]
clap = "4"

Could be written as:

[package]
name = "libc"

[dependencies]

(since libc doesn't use clap)

[epage]

Originally taken from https://blog.rust-lang.org/inside-rust/2024/10/01/this-development-cycle-in-cargo-1.82/#detecting-unused-dependencies

rustc has an unused dependencies lint but it can only report for one build unit but there can be multiple build units for a single dependencies table, leading to false positives, e.g.

[package]
name = "cargo"

[dependencies]
clap = "4"

could report clap as unused for the internal-only lib despite being used for the bin

See also

• unused_crate_dependencies false-positives in Cargo packages with muliple Cargo Targets (lib, bins, examples, tests, benches) rust#95513
• 2018: fix lint on unused dependencies rust#57274

With rust-lang/compiler-team#674, cargo can aggregate the unused dependencies from all of the build targets and report them to the user if none of the build targets use it.

Problem: Build-target filtering

If the package has multiple bins and the user does cargo check --bin foo, then Cargo will have incomplete information to report unused dependencies.

Solution: we'll need to only report unused dependencies if all build units that use a given dependency table are built

• [build-dependencies]: all package.build must be built (see Tracking issue for RFC 2196, "metabuild: semantic build scripts for Cargo" #14903 for "all"), except those skipped by required-features
• [dependencies]: all [lib] and all [[bin]] except those skipped by required-features
• [dev-dependencies]: all [[test]], [[example]], [[bench]], and doctests except those skipped by required-features

Downsides:

• For library-first packages with a bin, this won't detect when a dependency is unused by the library and can be limited to only be used by the bin through a feature
• Tracking enabled build targets and waiting for all of them to be done building could end up being tricky to implement
  • This would also mean that cargo check in one package may produce a warning but then when you move to a dependent, it won't because only the lib will build

Doctests?

cargo check --all-targets does not include doctests, so we can never check dev-dependencies.

https://blog.rust-lang.org/inside-rust/2024/10/01/this-development-cycle-in-cargo-1.82/#all-targets-and-doc-tests proposes we start building doctests with an --all-crates flag. This might require, directly or indirectly, a major rework to doctests, see rust-lang/testing-devex-team#5

In the mean time, we could either

• Not implement checking of dev-dependencies, allowing use immediately
• Implement checking of dev-dependencies but with false positives when it comes to deps only used by doctests, allowing people to find the greatest number of unused deps at the cost that it can't be checked in CI

An input into the above is that dev-dependencies only impact local development while build-dependencies and normal-dependencies also impact dependents.

[weihanglo]

While Cargo may have more precise information than external plugins, these are good tools people may want to know their user experience:

• https://crates.io/crates/cargo-udeps
• https://crates.io/crates/cargo-machete