unnecessary_lazy_evaluations suggestion causes panic on bool::then

[barryfam]

Summary

Clippy does not consider the possibility of arithmetic underflow in the non-lazy suggestion

Lint Name

unnecessary_lazy_evaluations

Reproducer

fn f(x: usize) -> Option<usize>
{
    (x >= 5).then(|| x - 5)
    // (x >= 5).then_some(x - 5)  // clippy suggestion panics
}

fn main() {
    let x = f(3);
    println!("{:?}", x);
}

clippy output:

    Checking playground v0.0.1 (/playground)
warning: unnecessary closure used with `bool::then`
 --> src/main.rs:3:5
  |
3 |     (x >= 5).then(|| x - 5)
  |     ^^^^^^^^^--------------
  |              |
  |              help: use `then_some(..)` instead: `then_some(x - 5)`
  |
  = note: `#[warn(clippy::unnecessary_lazy_evaluations)]` on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_lazy_evaluations

warning: `playground` (bin "playground") generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 0.68s

Version

rustc 1.65.0-nightly (8c6ce6b91 2022-09-02)
binary: rustc
commit-hash: 8c6ce6b91b172f77c795a74bfeaf74b865146b3f
commit-date: 2022-09-02
host: x86_64-unknown-linux-gnu
release: 1.65.0-nightly
LLVM version: 15.0.0

Additional Labels

No response

[clarkmoody]

I was hit by this bug as well.

[s-cerevisiae]

warning: unnecessary closure used with `bool::then`
// ...
(x != 0).then(|| 1 / x)
^^^^^^^^^--------------
         |
         help: use `then_some(..)` instead: `then_some(1 / x)`

It also suggests to use then_some when it's possible to divide by zero, which is apparently incorrect.

[alokedesai]

What's the status of this? Any aim to fix this in future release? The fact that clippy auto-fixes this makes this especially problematic--any auto fix should be guaranteed to be a functional no-op, which is not the case here

[ia0]

This is more general than bool::then(). This also triggers with Option::unwrap_or():

x.checked_sub(y).unwrap_or_else(|| y - x) // correct but linted
x.checked_sub(y).unwrap_or(y - x) // incorrect suggested fix

[y21]

The code that clippy uses for figuring out if a closure is necessary or not is shared between all of these lints, so a fix to bool::then will also apply to unwrap_or_else, map_or_else, or_insert_with, etc.
There's an open PR at #11002 that makes clippy avoid suggesting eagerness (then -> then_some) for arithmetic operations in closures (unless it can prove it cannot panic in some obvious cases)