Incorrect warning about unused const

[robz]

In the following program:

const SIZE: usize = 4;

fn _f(arr: [i32; SIZE]) {
    for x in arr.iter() {
      println!("{}", x);
    }
}

fn main() {}

I get a warning about SIZE being unused:

warning: constant item is never used: `SIZE`
 --> src/main.rs:1:1
  |
1 | const SIZE: usize = 4;
  | ^^^^^^^^^^^^^^^^^^^^^^
  |

It seems to me that this warning isn't correct, since SIZE is used in the signature of _f

[ExpHP]

This is because _f is not used; the unused lint applies transitively.

The most I've managed to dig up thus far on the reasoning behind this is this ancient post.

[robz]

Interesting, thanks for the background! I can see how the behavior here is consistent with the reasoning there, but I don't think the decision on that was the right one. Warnings like these have to be ignored, which reduces the signal/noise ratio of warnings in general.

[oli-obk]

Maybe an unused lint should have a note pointing to the "use site" in order to reduce said confusion

[ExpHP]

Edit (2019-10-16): I now firmly believe that the current design is inferior in all use cases, and have yet to see any description of a viable workflow for the use case of deleting all dead code given the current design.

---

I very much agree with @robz's sentiment. IMO, there are two use cases that an "unused" lint can be optimized for:

• The case where the correct resolution is to outright delete the code. This is the existing lint, though I'd rather call it a lint on unnecessary code rather than "unused" code. It indicates everything that is unnecessary all at once so that it can all be torn out in one fell swoop, which is useful for cleaning up code after e.g. replacing a dependency.

• The case where the correct resolution is to consider using the code (that is, you either need to add a use or silence the warning... or perhaps you're missing a pub or #[cfg(test)] or etc.). Each linted item is something independent that can be removed from the source code without any impact on compilation. I'll call this the truly unused lint.

Go figure, the latter always seems to be the one I actually need, but that might just be cognitive bias due to the "grass is greener" effect. Basically, it helps catch various classes of mistakes that otherwise elude the type system.

---

If we're stuck with having a single one of these two lints, then we have different issues:

• When trying to use the "unnecessary" lint to locate code that is truly unused, the issue is noise. Basically, the useful warnings are overwhelmed by many useless ones. I feel that @oli-obk's suggestion unfortunately would only help marginally here, by making the useless ones easier to spot. (Too bad it does this by making them occupy more space, when they are already greater in number!)

• When trying to use a "truly unused" lint to prune unnecessary code, the issue is that it's slow. Finding all of the unnecessary code may take many recompilation cycles as you slowly remove things as they are revealed.

[ExpHP]

Strawman idea:

#![allow(unused)]        // disable all unused warnings...
#![warn(truly_unused)]   // ...then reenable warnings for a subset of them

[oli-obk]

We could collect all unused things in a graph and report it starting with the items that have no incoming edges ( truly unused)

That way the important things show up first

[steveklabnik]

Triage: the error message is the same today, and I'm not aware of anyone working on the "point to the 'use' site" idea either.

[tkaitchuck]

There is already another issue open on this: #39531

[julianlalu]

I have the same problem when the crate have lib that define pub type and function ( actually extern "stdcall" pub fn ) and a bin that use the lib in the same crate.
#[test] in the lib do not complains, but binary complains about all imports that is not used
type alias is never used, associated const is never used and foreign function is never used.