Consider separate lints for "hierarchical" unused lints (or some way to opt-out)

[Houtamelo]

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

[workingjubilee]

@Houtamelo I think you've Berenstein Beared yourself: rustc emits two warnings as far back as 1.0 as far as I can tell.

[workingjubilee]

@Houtamelo If you want to implement the logic so that only the "unused root" would be linted on, I ¿think? we'd accept a decent/clean impl. It's just definitely not going to be a simple revert.

[bjorn3]

If two otherwise unused functions call each other, which would you consider to be the unused root? The first or last in source order? Both?

[est31]

I think the idea behind that behaviour was to not require people to do a cycle of removing the code, running the compiler, removing code again, etc. Instead, it points to all places that one would need to remove to be warning free, and then you have a fixpoint, at least that's the ideal (probably there is exceptions).

I think it depends from which point of view you are looking at it: if you want to remove the whole tree, or if you want to give the tree a new parent. In former case, it's useful to print all functions. In latter case, you might have removed some function call in order to move it somewhere else, and you only want to be warned about that function call. Both views are legitimate, but they are at odds with each other. I think a lot of users would dislike a "oh one more thing" reaction of the compiler though.

The idea of separating the lints would seems nice though, one for the (strongly connected components of) roots, one for the non-roots. It is a bit annoying though as we have multiple unused lints to consider. Should we separate all of the lints? Make only one lint for the recursive stuff?

@bjorn3

If two otherwise unused functions call each other, which would you consider to be the unused root?

In your example, I'd go for both. For a more general answer: the graph of usages is a directed graph. Directed graphs have strongly connected components. The graph of strongly connected components is cycle free. You have roots in that graph. One can emit lints for stuff belonging to the root components.

[Houtamelo]

@Houtamelo I think you've Berenstein Beared yourself: rustc emits two warnings as far back as 1.0 as far as I can tell.

That is possible (my memory isn't exactly great), though I have been using Rust for years and I don't remember these warnings being there past 12 months.

[Houtamelo]

If two otherwise unused functions call each other, which would you consider to be the unused root? The first or last in source order? Both?

Both.

[Houtamelo]

I think the idea behind that behaviour was to not require people to do a cycle of removing the code, running the compiler, removing code again, etc. Instead, it points to all places that one would need to remove to be warning free, and then you have a fixpoint, at least that's the ideal (probably there is exceptions).

I think it depends from which point of view you are looking at it: if you want to remove the whole tree, or if you want to give the tree a new parent. In former case, it's useful to print all functions. In latter case, you might have removed some function call in order to move it somewhere else, and you only want to be warned about that function call. Both views are legitimate, but they are at odds with each other. I think a lot of users would dislike a "oh one more thing" reaction of the compiler though.

The idea of separating the lints would seems nice though, one for the (strongly connected components of) roots, one for the non-roots. It is a bit annoying though as we have multiple unused lints to consider. Should we separate all of the lints? Make only one lint for the recursive stuff?

@bjorn3

If two otherwise unused functions call each other, which would you consider to be the unused root?

In your example, I'd go for both. For a more general answer: the graph of usages is a directed graph. Directed graphs have strongly connected components. The graph of strongly connected components is cycle free. You have roots in that graph. One can emit lints for stuff belonging to the root components.

I believe that one lint for the "recursive stuff" would be the most pragmatic approach. (#![allow(unused_recursive)]?)

[Houtamelo]

@Houtamelo If you want to implement the logic so that only the "unused root" would be linted on, I ¿think? we'd accept a decent/clean impl. It's just definitely not going to be a simple revert.

I'll start digging then.