As this is a lint about "style", and a purely cosmetical choice (using `<A: Trait>` over `impl Trait`), a lot of other files needed to be allowed this lint.
Ignore synthetic type parameters for `extra_unused_type_parameters`
There was a minor bug around calculating spans when forming the help message. An example:
```rust
fn unused_opaque<A, B>(dummy: impl Default) {}
// ^^ ^
```
In this case, the entire list of generics should be highlighted, instead of each individual parameter. The culprit is the `impl Default`, which registers as a type parameter but doesn't live within the `<...>`. Because synthetic parameters can't ever be manually created, we just ignore them for this lint.
r? `@flip1995`
changelog: none
<!-- changelog_checked -->
Fix false positives for `extra_unused_type_parameters`
Don't lint external macros. Also, if the function body is empty, any type parameters with bounds on them are not linted. Note that only the body needs be empty - this rule still applies if the function takes any arguments.
fixes#10318fixes#10319
changelog: none
<!-- changelog_checked -->
uninlined_format_args: do not inline argument with generic parameters
Fix#10339
---
changelog: FP: [`uninlined_format_args`]: No longer lints for arguments with generic parameters
[#10343](https://github.com/rust-lang/rust-clippy/pull/10343)
<!-- changelog_checked -->
fix [`needless_return`] incorrect suggestion when returning if sequence
fixes: #10049
---
changelog: [`needless_return`]: fix incorrect suggestion on if sequence
Liberate late-bound regions rather than erasing them in `needless_pass_by_value`
changelog: [`needless_pass_by_value`]: fixes an ICE when there are late-bound regions in function arguments that are needlessly passed by value
Fixesrust-lang/rust#107147
r? `@matthiaskrgr`
manual_let_else: let/else is not divergent by default
The divergent `else` block of a `let`/`else` statement does not make the `let/else` statement itself divergent.
Fixes#10296
changelog: [`manual_let_else`]: do not consider `let`/`else` to be divergent by default
[never_loop] Fix#10304
It is not sufficient to ignore break from a block inside the loop. Instructions after the break must be ignored, as they are unreachable. This is also true for all instructions in outer blocks and loops until the right block is reached.
Fixes#10304
---
changelog: FP: [`never_loop`]: No longer lints, for statements following break statements for outer blocks.
[#10311](https://github.com/rust-lang/rust-clippy/pull/10311)
<!-- changelog_checked-->
It is not sufficient to ignore break from a block inside the loop.
Instructions after the break must be ignored, as they are unreachable.
This is also true for all instructions in outer blocks and loops
until the right block is reached.
lintcheck: fix clap panic
clap 4.1.4 panics if `-` is used at the start of an argument:
```
$ cargo lintcheck
[…]
thread 'main' panicked at 'Argument recursive: long "--recursive" must not start with a `-`, that will be handled by the parser', /home/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-4.1.4/src/builder/debug_asserts.rs:82:13
```
changelog: none
<!-- changelog_checked -->
Clap was updated in rust-lang/rust-clippy#10270, which broke the command
line of clippy_dev. This swaps out contains_id, which now returns always
true in the places it was used with get_flag.
Make `[clippy::dump]` support trait items
Roses are red,
violets are blue,
trait items are rare,
`[clippy::dump]` is too
---
Let's just ignore the horrible poem... anyways. While working on Marker I noticed, that `[clippy::dump]` doesn't work on trait item (See [Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e2d9791ffa2872e7c09a9dfbd470350c)). This simply adds support for that. `[clippy::dump]` doesn't have UI tests, to make it more resistant to changes in the AST. I tested it locally and the dump works after these changes.
---
changelog: none
Negate suggestions when needed in `bool_assert_comparison`
changelog: none assuming this gets into the same release as #10218Fixes#10291
r? `@dswij`
Thanks to `@black-puppydog` for spotting it early
fix(suspicious_to_owned): use span_suggestions to suggest both intents
fixes#10294
changelog: [`suspicious_to_owned`]: suggestions now produce valid Rust code
