Enable warn(unused_crate_dependencies) on rustc_*` crates

[nnethercote]

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 merge on either the MCP or the PR.
• 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.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

@rfcbot concern reason-for-concern 
<description of the concern> 

Concerns can be lifted with:

@rfcbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[oli-obk]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted