fix#14034
The currect implementation of `obfuscated_if_else` sometimes makes
incorrect suggestions when the original code have side effects (see the
example in the above issue). I think this can be fixed by changing the
applicability depending on whether it can have side effects or not.
changelog: [`obfuscated_if_else`]: change applicability when the
original code can have side effects
I opened https://github.com/rust-lang/rust-clippy/pull/13896 before.
However, I found that there're more cases where Clippy suggests to use
modules that belong to the `std` crate even in a `no_std` environment.
Therefore, this PR include the changes I've made in #13896 and new
changes to fix cases I found this time to prevent wrong suggestions in
`no_std` environments as well.
changelog: [`redundant_closure`]: correct suggestion in `no_std`
changelog: [`repeat_vec_with_capacity`]: correct suggestion in `no_std`
changelog: [`single_range_in_vec_init`]: don't emit suggestion to use
`Vec` in `no_std`
changelog: [`drain_collect`]: correct suggestion in `no_std`
changelog: [`map_with_unused_argument_over_ranges`]: correct suggestion
in `no_std`
also close#13895
Receivers which are references to `Option` and `Result`, or who
implement `Deref` to one of those types, will be linted as well.
changelog: [`unnecessary_map_or`]: work with ref and `Deref` to `Option`
and `Result` as well
Fixes#14023
**Note:** this patch must be merged after #13998 – only the second
commit must be reviewed, the first one repeats the patch in #13998 for
mergeability reasons.
part of https://github.com/rust-lang/rust-clippy/issues/9100
The `obfuscated_if_else` lint currently only triggers for the pattern
`.then_some(..).unwrap_or(..)`, but there're other cases where this lint
should be triggered, one of which is `.then(..).unwrap_or(..)`.
changelog: [`obfuscated_if_else`]: trigger lint for the
`.then(..).unwrap_or(..)` pattern as well
This lint detects and removes the unnecessary semicolon after a `match`
or `if` statement returning `()`. It seems to be quite a common
"mistake", given the number of hits (88) we had in the Clippy sources
themselves.
The lint doesn't bother about loops, as `rustfmt` already removes the
extra semicolon. It doesn't handle blocks either, as an extra block
level, followed or not by a semicolon, is likely intentional.
I propose to put the lint in `pedantic`, as putting it in `style` seems
quite hazardous given the number of hits.
Note: there exists a `redundant-semicolon` lint in the compiler, but it
is an early lint and cannot check that the expression evaluates to `()`,
so it ignores the cases we're handling here.
----
changelog: [`unnecessary_semicolon`]: new lint
A multipart suggestion will be used whenever the method call can be
replaced by another one with the first argument removed. It helps place
the new method call in context, especially when it is part of a larger
expression.
This fixes#13995 by applying a suggestion made by @y21.
r? @y21
changelog: [`unnecessary_map_or`]: better representation of suggestions
by placing them in context
A multipart suggestion will be used whenever the method call can be
replaced by another one with the first argument removed. It helps place
the new method call in context, especially when it is part of a larger
expression.
Removing `.map(identity)` may result in invalid code if the receiver of
`map()` is an immutable binding, and the result of `map()` is used as
the receiver of a method call expecting a mutable reference.
Fix#13904
changelog: [`map_identity`]: do not lint if this would cause mandatory
mutability to be lost
When the expression is transformed into an equality, parentheses are
needed only if the resulting equality is used:
- as a receiver in a method call
- as part of a binary or unary expression
- as part of a cast
In other cases, which will be the majority, no parentheses are required.
This makes the lint suggestions cleaner.
changelog: `none`
Fixes https://github.com/rust-lang/rust-clippy/issues/8528.
Similar to #13911, if there are code comments, we don't want to remove
them automatically.
changelog: Don't emit machine applicable `map_flatten` lint if there are
code comments
r? @xFrednet
fixes: #4077
Continuation of #11546. r? @y21 if you don't mind?
changelog: [`needless_continue`] lint if the last stmt in loop is
`continue` recurisvely
When the expression is transformed into an equality, parentheses are
needed only if the resulting equality is used:
- as a receiver in a method call
- as part of a binary or unary expression
- as part of a cast
In other cases, which will be the majority, no parentheses are required.
This makes the lint suggestions cleaner.
Removing `.map(identity)` may result in invalid code if the receiver of
`map()` is an immutable binding, and the result of `map()` is used as
the receiver of a method call expecting a mutable reference.
