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
Add test for and fix rust-lang/rust-clippy#9131
This lint seems to have been broken by #98446 -- but of course, there was no clippy test for this case at the time.
`expr.span.ctxt().outer_expn_data()` now has `MacroKind::Derive` instead of `MacroKind::Attr` for something like:
```
#[derive(Clone, Debug)]
pub struct UnderscoreInStruct {
_foo: u32,
}
```
---
changelog: none
closes: https://github.com/rust-lang/rust-clippy/issues/9131
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
Make MIR basic blocks field public
This makes it possible to mutably borrow different fields of the MIR
body without resorting to methods like `basic_blocks_local_decls_mut_and_var_debug_info`.
To preserve validity of control flow graph caches in the presence of
modifications, a new struct `BasicBlocks` wraps together basic blocks
and control flow graph caches.
The `BasicBlocks` dereferences to `IndexVec<BasicBlock, BasicBlockData>`.
On the other hand a mutable access requires explicit `as_mut()` call.
Finishing touches for `#[expect]` (RFC 2383)
This PR adds documentation and some functionality to rustc's lint passes, to manually fulfill expectations. This is needed for some lints in Clippy. Hopefully, it should be one of the last things before we can move forward with stabilizing this feature.
As part of this PR, I've also updated `clippy::duplicate_mod` to showcase how this new functionality can be used and to ensure that it works correctly.
---
changelog: [`duplicate_mod`]: Fixed lint attribute interaction
r? `@wesleywiser`
cc: https://github.com/rust-lang/rust/issues/97660, https://github.com/rust-lang/rust/issues/85549
And I guess that's it. Here have a magical unicorn 🦄
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`.
