Lint suggestion: opt-in workspace-wide `dead_code` analysis

Usage Scenario

To combat compile times and to improve structure of their Rust code, people often tend to use a Cargo workspace and split up their crate into many smaller crates forming a workspace.

One very big downside to this approach is the following:

The APIs of those workspace crates are no longer strictly bound to the workspace and thus dead_code analysis won't flag APIs even if their intent is to be consumed by other workspace crates.

Example: Before, we had a module b in crate a. When b exposed an item that was not used, rustc (or clippy) would flag it as dead_code. Now that b is its own crate and crate a depends on crate b we no longer receive any dead_code warnings for b's items if they aren't used by a. The rational is that b is a fully fledged crate and might have other dependents besides a.

Needless to say this can lead to garbage accumulation in especially large workspaces.

Lint Idea

The ideal solution is a new lint that would be disabled by default and that could be opt-in enabled per crate would analyse the workspace's crate dependency graph to detect which crates are such "utility" crates - i.e. the ones used by other crates in the workspace. If the new lint is enabled for those crates, clippy would perform a dead_code analysis local to the crate and local to the crate's workspace, i.e. check for all of its workspace's dependents (and itself) what APIs items are unused and flag them.

I hope this is feasible to implement in clippy and won't require major cargo integration or so. It would certainly be a huge help for pretty much all the large workspaces I have ever worked at.

Advantage

Detect dead_code within a workspace.

• Improve compile time.
• Decrease binary artifact sizes.
• Declutter workspace-related crates.
• Improve dealing with tech-debt within workspaces.

Drawbacks

None, since the new lint is explicitly opt-in so the user decides which crates are meant to be utilities within the workspace.

Example: Workspace

Crate b

pub fn foo() {}
pub fn bar() {} // ~ WARN: `dead_code` within the crate's workspace

Crate a

use b::foo;
pub fn baz() { foo(); }

Could be written as:

Crate b

pub fn foo() {}

Comparison with existing lints

Rust's current dead_code analysis is crate local.
From my research so far there currently does not exist a cargo plugin or clippy pass to perform this kind of workspace-local dead_code analysis.

No files, tests, or entry points are named. Begin by locating Clippy's current crate-local dead_code analysis, then establish how an opt-in workspace-wide check should identify unused public APIs and verify the example where bar is flagged while foo remains used.