Let_unit_value false positive when return type is type parameter

[dtolnay]

fn main() {
    let _: () = f();
}

fn f<T: Default>() -> T {
    T::default()
}

warning: this let-binding has unit value. Consider omitting `let _ =`, #[warn(let_unit_value)] on by default
 --> src/main.rs:2:5
  |
2 |     let _: () = f();
  |     ^^^^^^^^^^^^^^^^
  |
  = help: for further information visit https://github.com/Manishearth/rust-clippy/wiki#let_unit_value

Maybe this specific case would be clearer with f::<()>() but I consider this a false positive. Came up in serde_json unit tests where we test that serde_json::from_str can parse various representations of ().

[oli-obk]

we need to check whether the rhs contains any type inference.

[oli-obk]

I'm not sure how to solve this. This will need some forensics first to figure out whether rustc can tell us if it used inference.

[dtolnay]

I think it would work to recognize just this specific pattern: return type consists entirely of a type parameter that is not used by any of the argument types. In that case permit let_unit_value.

[hellow554]

This is an interesting thing I stumpled upon today.

I would say that your code @dtolnay should still be linted, because you assign the unit value to a named variable (although it has an underscore, but that doesn't matter here ;) )

I would let clippy suggest doing this:

let () = f();

This would still let the compiler infer the type but telling the user, that he can't do anything with the unit value.
Or can you think of a specific use case where you need a variable name?

[dtolnay]

let _: () does not assign a named variable.

[hellow554]

I somehow saw let _a: (), don't ask me why... (:

[lilyball]

This fix for this doesn't work for me. Approximate code:

let (_tx, rx) = oneshot::channel();
let handle = spawn(async {
    let () = rx.await.unwrap();
});

This triggers the lint in 1.62.0 (now that it defaults to warn). Using let _: () = … also triggers it. The let-binding here is most certainly required for type inference.

[lilyball]

It sounds like #8998 might cover my case, though I don't know how that is different from the issue described here.