Having a macro call as the scrutinee is supported. However, the proposed
suggestion must use the macro call itself, not its expansion.
When the scrutinee is a macro call, do not complain about an irrefutable
match, as the user may not be aware of the result of the macro. A
comparaison will be suggested instead, as if we couldn't see the outcome
of the macro.
Similarly, do not accept macro calls as arm patterns.
changelog: [`single_match`]: proper suggestions in presence of macros
Fixes#14493
These method chains can be expressed concisely with `if` / `else`.
changelog: [`obfuscated_if_else`]: support `then().unwrap_or_default()`
and `then_some().unwrap_or_default()`
Having a macro call as the scrutinee is supported. However, the proposed
suggestion must use the macro call itself, not its expansion.
When the scrutinee is a macro call, do not complain about an irrefutable
match, as the user may not be aware of the result of the macro. A
comparaison will be suggested instead, as if we couldn't see the outcome
of the macro.
Similarly, do not accept macro calls as arm patterns.
Until `if let` chains are stabilized, we do not collapse them together
or with other `if` expressions unless the `let_chains` feature is
enabled. This is the case for example in Clippy sources.
This was made possible by converting the `collapsible_if` to a late lint
to get access to the set of enabled features. This allows this PR to
supersede #14455 and no longer require an additional configuration
option.
The three commits are, in order:
- a conversion of the existing early lint to a late lint, with no new
feature or tests changes
- the addition of the `let_chains` feature detection and action, and
tests
- the application of the enhanced lint to Clippy sources (136 files
modified)
changelog: [`collapsible_if`]: recognize the rust compiler `let_chains`
feature
r? @flip1995
The `unnecessary_filter_map` and `unnecessary_find_map` lints were
making partial suggestions, proposing to replace the whole expression by
only the method name, or a subexpression which contained explicit
placeholders.
Since even `MaybeIncorrect` suggestions must generate code that
compiles, this changes those lints to recommandation lints with no
code suggestion.
Until `if let` chains are stabilized, we do not collapse them together
or with other `if` expressions unless the `let_chains` feature is
enabled. This is the case for example in Clippy sources.
When lowering a destructuring assignment from AST to HIR, the compiler
will reuse the same identifier name (namely `sym::lhs`) for all the
fields. The desugaring must be checked for to avoid a false positive of
the `shadow_unrelated` lint.
Fix#10279Fix#14377
changelog: [`shadow_unrelated`]: prevent false positive in destructuring
assignments
When lowering a destructuring assignment from AST to HIR, the compiler
will reuse the same identifier name (namely `sym::lhs`) for all the
fields. The desugaring must be checked for to avoid a false positive
of the `shadow_unrelated` lint.
Dereferencing string literals in suggestions is redundant.
changelog: [`cmp_owned`]: more natural suggestions are provided for
string literals now
fixes#8103
This extra condition prevents a problem when removing the '}' in:
```rust
( // There was an opening bracket after the parenthesis, which has been removed
// This is a comment
})
```
Removing the whitespaces, including the linefeed, before the '}', would put the
closing parenthesis at the end of the `// This is a comment` line, which would
make it part of the comment as well. In this case, it is best to keep the span
on the '}' alone.
Both lints share a lot of characteristics but were implemented in
unrelated ways. This unifies them, saving around 100 SLOC in the
process, and making one more test trigger the lint. Also, this removes
useless blocks in suggestions.
The `uninlined_format_args` was temporarily downgraded to `pedantic` in
part because rust-analyzer was not fully supporting it at the time, per
#10087. The support has been added over [a year
ago](https://github.com/rust-lang/rust-analyzer/issues/11260), so seems
like this should be back to style.
Another source of the initial frustration was fixed since then as well -
this lint does not trigger by default in case only some arguments can be
inlined.
changelog: [`uninlined_format_args`]: move back to `style`
This lint was downgraded to `pedantic` in part because rust-analyzer was not fully supporting it at the time per #10087. The support has been added over [a year ago](https://github.com/rust-lang/rust-analyzer/issues/11260), so seems like this should be back to style.
Another source of the initial frustration was fixed since then as well - this lint does not trigger by default in case only some arguments can be inlined.
Replace the use of `Sugg::ast()` which prevented combining `if` together
when they contained comments by span manipulation.
A new configuration option `lint_commented_code`, which is `true` by
default, allows opting out from this behavior.
If reviewed on GitHub, the second commit of this PR is best looked at
side by side, with whitespace differences turned off.
changelog: [`collapsible_if`]: lint more cases
#2597 appears to be already resolved, so the applicability of `op_ref`
can be set to `MachineApplicable`.
close#2597
changelog: [`op_ref`]: set the applicability to `MachineApplicable`
Replace the use of `Sugg::ast()` which prevented combining `if`
together when they contained comments by span manipulation.
A new configuration option `lint_commented_code`, which is `true` by
default, opts out from this behavior.
Closes#11346.
Partially fix#9905. The first case in this issue is a little tricky as
the coerce does not happen in the borrowing.
changelog: [`borrow_deref_ref`]: fix wrong suggestions when coerce to
mut
Closes#11617Closes#14368
Clippy gives wrong suggestions when the filter and then cannot be put
into closure directly. Since trying to transform these can be too
complicated, Clippy will simply warn but don't try to fix.
changelog: [`filter_map_bool_then`]: fix wrong suggestions when the
closure cannot be decompose directly
