Wired false negative of `clippy::extra_unused_type_parameters`

[mu001999]

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)

[y21]

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]

@y21 thanks for the context!

[mu001999]

@y21 I agree with not warning on empty functions that have some bounds T: Send, but if there are only generics like fn foo<'a, T>, I think maybe we can still warn on them?

[y21]

In this case there's still an implicit T: Sized bound, but even with T: ?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.rs

This tests that AsyncRead can 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]

@y21 Oh, I was just experimenting, so I think it's Okay ;)