- Notifications
You must be signed in to change notification settings - Fork 14.1k
Description
Description
Consider the example:
fn unused_foo() { used_bar_but_just_here(); } fn used_bar_but_just_here() {}In the past (I can't pinpoint when), cargo check would emit a "unused" warning for unused_foo, but not used_bar_but_just_here, like so:
warning: function `unused_foo` is never used --> src/main.rs:6:4 | 6 | fn unused_foo() { used_bar_but_just_here(); } | ^^^^^^^^^^ | = note: `#[warn(dead_code)]` on by default Nowadays, cargo check emits unused warnings for both:
warning: function `unused_foo` is never used --> src/main.rs:6:4 | 6 | fn unused_foo() { used_bar_but_just_here(); } | ^^^^^^^^^^ | = note: `#[warn(dead_code)]` on by default warning: function `used_bar_but_just_here` is never used --> src/main.rs:8:4 | 8 | fn used_bar_but_just_here() {} | ^^^^^^^^^^^^^^^^^^^^^^ The new behavior is really disruptive and annoying, as it marks your entire method "tree" with unused instead of just the root, which litters the codebase with warnings during prototype stages. It also fails to pinpoint the "real culprit".
Another point: As a user, I expect that removing unused items shouldn't cause compiler errors, in the example, cargo check complains that used_bar_but_just_here is never used, yet removing it would cause a compiler error since unused_foo does use that method.
If I may suggest, one of these options would really be appreciated (I'm willing to make the PR myself if any of these is accepted):
- Revert to the old behavior (I personally can't think of a situation where I would miss the new behavior).
- Move the new behavior to a different lint (something like
unused_chained?) or add that new lint to represent the old behavior.
Version
rustc 1.86.0 (05f9846f8 2025-03-31) binary: rustc commit-hash: 05f9846f893b09a1be1fc8560e33fc3c815cfecb commit-date: 2025-03-31 host: x86_64-unknown-linux-gnu release: 1.86.0 LLVM version: 19.1.7