change applicability type to MaybeIncorrect in `explicit_counter_loop`
close#9013
This PR changes applicability type to `MaybeIncorrect`, because the suggestion is not `MachineApplicable`.
changelog: change applicability type to MaybeIncorrect in `explicit_counter_loop`
Fixes for `branches_sharing_code`
fixes#7198fixes#7452fixes#7555fixes#7589
changelog: Don't suggest moving modifications to locals used in any of the condition expressions in `branches_sharing_code`
changelog: Don't suggest moving anything after a local with a significant drop in `branches_sharing_code`
Fix Clippy version in `derive_partial_eq_without_eq` lint
It was first added to Rust in https://github.com/rust-lang/rust/pull/97248 which missed 1.62 just by few days.
changelog: none
Fix span for or_fun_call
Closes#9033
changelog: [`or_fun_call`]: span points to the `unwrap_or` only instead of through the entire method chain expression
Ignore `into_iter` in `significant_drop_in_scrutinee`
fixes#9135
changelog: Ignore the `IntoIterator::into_iter` call from for loops in `significant_drop_in_scrutinee`
* Don't suggest moving modifications to locals used in any of the condition expressions
* Don't suggest moving anything after a local with a significant drop
Simplify if let statements
fixes: #8288
---
changelog: Allowing [`qustion_mark`] lint to check `if let` expressions that immediatly return unwrapped value
Lint simple expressions in `manual_filter_map`, `manual_find_map`
changelog: Lint simple expressions in [`manual_filter_map`], [`manual_find_map`]
The current comparison rules out `.find(|a| a.is_some()).map(|b| b.unwrap())` because `a` being a reference can effect more complicated expressions, this adds a simple check for that case and adds the necessary derefs
There's some overlap with `option_filter_map` so `lint_filter_some_map_unwrap` now returns a `bool` to indicate it linted
Fix ICE in sugg::DerefDelegate with (named) closures
rustc comiler internals helpfully tell us how to fix the issue:
```
to get the signature of a closure, use `substs.as_closure().sig()` not `fn_sig()`
```
Fixes ICE in #9041
This also makes this code in `sugg::DerefDelegate` match a different use `typ.fn_sig(…)` I found: in `mixed_read_write_in_expression` -- being strict on the value of `typ.kind()` will hopefully reduce any future possibility of ICE crashes in this area.
---
changelog: none
rustc comiler internals helpfully tell us how to fix the issue:
to get the signature of a closure, use `substs.as_closure().sig()` not `fn_sig()`
Fixes ICE in #9041
the two loops did practically the same, only the type were different (&&
vs &), so I used `copied` to convert `&&` and chained them together.
Instead of parsing the trait info manually, I use the already provided
method `get_trait_info_from_bound`.
Also, instead of using manual string writing, I used `join` by
`itertools`.
Fix `undocumented_unsafe_blocks` in closures
fixes#9114
changelog: Fix `undocumented_unsafe_blocks` not checking for comments before the start of a closure
`new_without_default`: ignore const generics/lifetime params on `fn new`
Fixes#9113
No longer lints if `fn new` has any params
changelog: [`new_without_default`]: no longer lints const generics and lifetime params on `fn new`
Add `invalid_utf8_in_unchecked`
changelog: Add [`invalid_utf8_in_unchecked`]
closes: #629
Don't know how useful of a lint this is, just saw this was a really old issue 😄.
