Description
Proposal
It's bad having unused dependencies in Cargo.toml files. There's probably some kind of compile time cost, but more importantly, it's just misleading when reading the code.[*]
In the past I have looked for unused dependencies in a brute force fashion: comment out all dependencies in a Cargo.toml file, and then add them back in until it compiles again. This works but is slow and tedious.
Then I learned the unused_crate_dependencies lint, which is much better. In rust-lang/rust#126063 I removed 19 unused dependencies that I found by changing unused_crate_dependencies from Allow to Warn. But there were a few false positives so doing this everywhere didn't seem feasible.
Today I redid this exercise and found another 15 unused dependencies that had crept in over the past nine months. (And I recently removed another two in rust-lang/rust#137776 that I found with my own eyeballs.) Based on that, I think it's worth pushing harder on enabling this lint for the compiler.
I propose adding warn(unused_crate_dependencies) to all rustc_* crates, except for those where the lint gives false positives, which would instead get allow(unused_crate_dependencies) along with an explanatory comment.
(An alternative is to pass -Wunused-crate-dependencies to all rustc_* crates. That would require touching fewer lines, and would also automatically extend the functionality to new crates.)
[*] Something I look at quite often is a graph of the crate dependencies, generated with these commands:
cargo +nightly depgraph --all-deps --dedup-transitive-deps --workspace-only > ~/graph.dot;
dot -Tpng ~/graph.dot > ~/graph.png
Here is an example one:
It's good to not have unused edges in this graph.
Mentors or Reviewers
None. Two possible PRs implementing this are at rust-lang/rust#137911 and rust-lang/rust#137930.
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.