let_underscore_untyped fails to consider configured msrv

[dtolnay]

Summary

Clippy's let_underscore_untyped lint triggers on code that is 100% good and idiomatic in projects that target 1.58 or older.

Lint Name

let_underscore_untyped

Reproducer

// src/main.rs

#![deny(clippy::pedantic)]

fn f() -> Result<u8, ()> {
    Err(())
}

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

# .clippy.toml

msrv = "1.58.0"

$ cargo clippy

error: non-binding `let` without a type annotation
 --> src/main.rs:8:5
  |
8 |     let _ = f();
  |     ^^^^^^^^^^^^
  |
  = help: consider adding a type annotation or removing the `let` keyword
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_underscore_untyped
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![deny(clippy::pedantic)]
  |         ^^^^^^^^^^^^^^^^
  = note: `#[deny(clippy::let_underscore_untyped)]` implied by `#[deny(clippy::pedantic)]`

Clippy's suggested code does not compile.

error[E0658]: destructuring assignments are unstable
 --> src/main.rs:8:5
  |
8 |     _ = f();
  |     ^
  |
  = note: see issue #71126 <https://github.com/rust-lang/rust/issues/71126> for more information

error[E0658]: destructuring assignments are unstable
 --> src/main.rs:8:7
  |
8 |     _ = f();
  |     - ^
  |     |
  |     cannot assign to this expression
  |
  = note: see issue #71126 <https://github.com/rust-lang/rust/issues/71126> for more information

Version

rustc 1.69.0-nightly (d962ea578 2023-02-26)
binary: rustc
commit-hash: d962ea57899d64dc8a57040142c6b498a57c8064
commit-date: 2023-02-26
host: aarch64-unknown-linux-gnu
release: 1.69.0-nightly
LLVM version: 15.0.7

Additional Labels

@rustbot label +I-suggestion-causes-error

[dtolnay]

Mentioning @JirkaVebr @llogiq since this lint is from #10356.

[Jarcho]

Doesn't seem like a false positive. I'm not sure what the point of the suggestion to remove the let keyword is for since it goes against the stated reason for the lint.

This might be better as a restriction lint. let _ = ... is used very frequently and there's nothing really wrong with it.

[dtolnay]

I'm not sure what the point of the suggestion to remove the let keyword is for

Based on the message outputted by the lint, I assumed this to be a "why waste time say lot word when few word do trick" lint: i.e. with the motivation that now that _ = ... is available, prevent people from writing let _ = ..., except if they wanted to put a non-inferred type, which is not supported by _ = ....

since it goes against the stated reason for the lint.

Yeah, going back and reading #6842, it seems my assumed interpretation is not at all the rationale behind the lint originally proposed. The purported reason that let _ = ... is bad also applies equally to _ = ....

[JirkaVebr]

@dtolnay First of all, I'm really sorry about this issue. This was my first ever contribution made at @llogiq's excellent Clippy workshop, and I'm definitely no expert on this.

The intention behind the lint wasn't primarily to save tokens by dropping the let, but rather to nudge people towards providing a type ascription, thereby explicitly stating what exactly is it that they wish to ignore. That way their compile would break should the type of the ignored expression change, and they would be forced to re-evaluate the decision to ignore the value. Perhaps once the type is different, they would no longer wish to ignore the value? Hence the name of the lint: let_underscore_untyped ‒ it's really about the type. The "dropping the let" part is intended primarily for cases where the type cannot be named, is too complex, or the author just doesn't wish to spell out the type. But yes, _ = <expr> does suffer from the same problem the lint is trying to address.

Based on the message outputted by the lint

Is the message too misleading then? Perhaps it should be more clear that the recommended resolution is to provide the type ascription?

Regarding the MSRV, that is just a bug and an oversight on our part, thanks for pointing that out. For older versions of Rust, should it not recommend dropping the let or should it just be disabled? 🤔

[dtolnay]

IMO clippy should not ever suggest replacing let _ = ... with _ = ..., regardless of msrv, since that is not better.

[smoelius]

This might be better as a restriction lint. let _ = ... is used very frequently and there's nothing really wrong with it.

I also think this might be better as a restriction lint.