Add a lint to suggest `ok_or_else()` for "expensive" values of `ok_or()` argument

[djc]

What it does

It would be nice to have the inverse of unnecessary_lazy_evaluations where clippy would suggest these translations:

• unwrap_or to unwrap_or_else
• and to and_then
• or to or_else
• get_or_insert to get_or_insert_with
• ok_or to ok_or_else
• then_some to then

if the argument to the original is "expensive" (non-const, function call other than enum tuple variant, etc).

Advantage

In rustls I recently wrote a PR that changed ok_or(Error::Foo) to ok_or(cx.send_fatal_alert(Error::Foo)), which broke a lot of stuff in somewhat non-obvious ways because it sent alerts eagerly rather than only in the actual error case.

Example

On seeing ok_or(cx.send_alert(Error::Foo)), suggest using ok_or_else(..) instead.

Comparison with existing lints

Similar to unnecessary_lazy_evaluations, but the other way around.

[y21]

The or_fun_call lint is sort of trying to do this. Although it is a little unfortunate that this name was chosen because it excludes some methods that don't exactly count as one of the "or" methods while the idea of unnecessary eager evaluation still applies.

At least your example should be caught by that lint.

[djc]

Ahh, I thought there was something like that. So what's the reason it's in the nursery?

[y21]

Looking at PR #9829, sounds like the reason is false positives. The main motivation of the lint is improving performance, but it's not really generally possible for clippy to tell whether a call is expensive or cheap. #8574 lists some trivial example calls where the lint's suggestion doesn't make a difference in perf

[ctz]

I think the framing I would use is whether the function has side effects, rather than being expensive/cheap. The const suggestion here, coupled with people using missing_const_for_fn widely, is quite close for clippy being able to make good-quality suggestions.