rust-lang
Allow more lazy evaluations
Update unnecessary_lazy_evaluations to allow closures for trivial functions according to the developer's preference.
The current list of trivial functions is is_empty, len, and as_*. This list cannot be updated without causing churn, because e.g., calls to unwrap_or_else and unwrap_or would need to be swapped for each addition and removal. This list is also undocumented and not based on actual method complexity, but repositories need to follow it to be compliant with this default lint. Leaving these trivial functions up to developer preference allows developers to not need to think about which functions Clippy considers lazy.
A configuration could be added later to re-enable this without any backward-compatibility concern, but it should not be enforced by default.
changelog: [unnecessary_lazy_evaluations]: allow optional closure for trivial functions
Fixes: rust-lang/rust-clippy#8109
r? @Jarcho
rustbot has assigned @Jarcho. They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.
Use r? to explicitly pick a reviewer
Lintcheck changes for de1028a03f39b2a079162132a49e8a8b796d8801
| Lint | Added | Removed | Changed |
|---|---|---|---|
clippy::if_then_some_else_none |
0 | 0 | 3 |
clippy::option_if_let_else |
0 | 0 | 2 |
clippy::unnecessary_lazy_evaluations |
0 | 12 | 0 |
This comment will be updated if you push new changes
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
:umbrella: The latest upstream changes (possibly e1130b694af2c503a8ce36b786b69c5e40b1f1e6) made this pull request unmergeable. Please resolve the merge conflicts.
This is not a good way to fix unnecessary_lazy_evaluations. The eager_or_lazy check is used by a lot a lints that will have a regression.
This is not saying there's nothing to fix here. unnecessary_lazy_evaluations should be far less aggressive in general, but it needs to be something targeted at that lint in particular.
@Jarcho Could you provide an example for me to consider? At least as far as I see this change, it only updates an Eager decision to NoChange, which should only accept more styles than previous. The related lints would also rightfully be updated to consider that a developer may intend for them to be lazily evaluated
The only change that I would expect to arguably be breaking would be recommendations, which as shown in the tests, now may suggest to use a closure for a simple function call. This would actually be more conservative as I see it