Repository navigation
Wired false negative of clippy::extra_unused_type_parameters #12820
Description
Summary
For the following code:
fn foo<T>() { () }
fn main() {
foo::<i32>();
}We can get:
warning: unneeded unit expression
--> src/main.rs:1:15
|
1 | fn foo<T>() { () }
| ^^ help: remove the final `()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unused_unit
= note: `#[warn(clippy::unused_unit)]` on by default
warning: type parameter `T` goes unused in function definition
--> src/main.rs:1:7
|
1 | fn foo<T>() { () }
| ^^^ help: consider removing the parameter
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#extra_unused_type_parameters
= note: `#[warn(clippy::extra_unused_type_parameters)]` on by default
But no warning after removing the unneeded unit expression in foo.
Lint Name
extra_unused_type_parameters
Reproducer
I tried this code:
fn foo<T>() {}
fn main() {
foo::<i32>();
}I expected to see this happen:
warning: type parameter `T` goes unused in function definition
--> src/main.rs:1:7
|
1 | fn foo<T>() { () }
| ^^^ help: consider removing the parameter
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#extra_unused_type_parameters
= note: `#[warn(clippy::extra_unused_type_parameters)]` on by default
Instead, nothing happened.
Version
1.80.0-nightly
(2024-05-18 b1ec1bd65f89c1375d2c)
Activity
y21 commentedon May 19, 2024
The lint intentionally does not warn on empty functions since it's often used to statically assert that a type satisfies some bounds: #10319
mu001999 commentedon May 19, 2024
@y21 thanks for the context!
mu001999 commentedon May 19, 2024
@y21 I agree with not warning on empty functions that have some bounds
T: Send, but if there are only generics likefn foo<'a, T>, I think maybe we can still warn on them?y21 commentedon May 19, 2024
In this case there's still an implicit
T: Sizedbound, but even withT: ?Sized, it might still be used to assert that a type is well formed: https://github.com/tokio-rs/tokio/blob/master/tokio/tests/io_async_read.rsThis tests that
AsyncReadcan be made into a trait object and it would generate an error if the traits were not object safe.But to be fair, this could've also been written
fn _assert(_: Box<dyn AsyncRead>) {}to avoid the warning.I'm not sure how common assertions (with no bounds) like that are though. If it's very rare and prevents a lot of true positives, it might be worth accepting those assertions as a false positive and emitting a warning anyway and just requiring people to add an
#[allow].But empty functions also seem like the kind of thing that seem useless at first glance but people use them for all kinds of hacks, so maybe it's good to be cautious around them, and I'm not sure if there are real world cases for empty functions where a warning would be useful. How did you run into this false negative, was this real code or were you just experimenting?
mu001999 commentedon May 19, 2024
@y21 Oh, I was just experimenting, so I think it's Okay ;)