When the manually stripped entity receives a name as the first use
through a simple `let` statement, this name can be used in the generated
`if let Some(…)` expression instead of a placeholder.
Fix#14183
changelog: [`manual_strip`]: reuse existing identifier in suggestion
when possible
For some reason, the `todo!` and `unimplemented!` macros were not
included in the list of format-supporting macros list. Since they seem
to behave exactly the same as all others like `write!` and `assert!`,
adding them now.
I wonder if we should delete the `FORMAT_MACRO_DIAG_ITEMS`, and instead
tag all macros with the `#[clippy::format_args]`?
changelog: all format-handling lints will now validate `todo!` and
`unimplemented!` macros.
These method chains can be expressed concisely with `if`/`else`.
changelog: [`obfuscated_if_else`]: support `then().unwrap_or_else()` and
`then_some().unwrap_or_else()`
```rust
let mut tmp = vec![1, 2, 3];
for b in &mut tmp {
*b = !*b;
}
```
must not suggest the invalid `tmp.fill(!*b)`.
In addition, there is another commit which cleans up two function calls
with no effect.
Fix#14189
changelog: [`manual_slice_fill`]: ensure that the initialization
expression doesn't reference the iterator
- The name of an MSRV alias should describe its functionality, and it is
not appropriate for it to be the same as the name of the lint that uses
it.
- Additionally, while `manual_div_ceil` allows setting MSRV, this is not
correctly reflected in the configuration information.
changelog: none
For some reason, the `todo!` and `unimplemented!` macros were not included in the list of format-supporting macros list. Since they seem to behave exactly the same as all others like `write!` and `assert!`, adding them now.
Roses are red,
Biolets are blue,
A typo happened,
too late now
You might be asking,
what are Biolets now?
And to be honest,
I have no clue
---
The cat of this release is `Vera` nominated by @and-reas-se
<img height=500
src="https://github.com/user-attachments/assets/82e6fccc-1f6d-4d29-b6bb-0bd4f3584593"
alt="The cats of this Clippy release" />
Cats for the next release can be nominated in the comments :D
---
changelog: none
fixes#13934
I modified the part for checking if the map is used so that it can check
field and index exprs.
changelog: [`map_entry`]: fix FP on struct member
In the case where `iter` is a `DoubleEndedIterator`, replacing a call to
`iter.last()` (which consumes `iter`) by `iter.next_back()` (which
requires a mutable reference to `iter`) cannot be done when `iter` is a
non-mutable binding which is not a mutable reference. When possible, a
local immutable binding is made into a mutable one.
Also, the applicability is switched to `MaybeIncorrect` and a note is
added to the output when the element types have a significant drop,
because the drop order will potentially be modified because
`.next_back()` does not consume the iterator nor the elements before the
last one.
Fix#14139
changelog: [`double_ended_iterator_last`]: do not trigger on
non-reference immutable receiver, and warn about possible drop order
change
`iter.last()` will drop all elements of `iter` in order, while
`iter.next_back()` will drop the non-last elements of `iter` when
`iter` goes out of scope since `.next_back()` does not consume its
argument.
When the transformation proposed by `double_ended_iterator_last` would
concern an iterator whose element type has a significant drop, a note is
added to warn about the possible drop order change, and the suggestion
is switched from `MachineApplicable` to `MaybeIncorrect`.
In the case where `iter` is a `DoubleEndedIterator`, replacing a call to
`iter.last()` (which consumes `iter`) by `iter.next_back()` (which
requires a mutable reference to `iter`) cannot be done when `iter`
Is not a mutable binding or a mutable reference.
When `iter` is a local binding, it can be made mutable by fixing its
definition site.
Continuing the work started in #136466.
Every method gains a `hir_` prefix, though for the ones that already
have a `par_` or `try_par_` prefix I added the `hir_` after that.
If the part being replaced is an `if` expression following an `else`,
the replacement expression must be blockified.
Fix#14239
changelog: [`manual_ok_err`]: fix replacement expression if it follows
an `else`
This lint was renamed in 50da77521e.
While I'm here convert the list of separate lints into a proper list for
ease of use and clarify which lints are in clippy and which are in rustc.
Allows creating a toolchain that's independent of the local build, for
example to make two separate toolchains with slight differences without
requiring two checkouts of clippy
changelog: none
Some developers might prefer to use alternate VCS, such as Jujutsu,
which are not detected by `cargo fix`. This forwards the
`--allow-no-vcs` command line argument to `cargo fix`.
changelog: none
First of all, note that `Map` has three different relevant meanings.
- The `intravisit::Map` trait.
- The `map::Map` struct.
- The `NestedFilter::Map` associated type.
The `intravisit::Map` trait is impl'd twice.
- For `!`, where the methods are all unreachable.
- For `map::Map`, which gets HIR stuff from the `TyCtxt`.
As part of getting rid of `map::Map`, this commit changes `impl
intravisit::Map for map::Map` to `impl intravisit::Map for TyCtxt`. It's
fairly straightforward except various things are renamed, because the
existing names would no longer have made sense.
- `trait intravisit::Map` becomes `trait intravisit::HirTyCtxt`, so named
because it gets some HIR stuff from a `TyCtxt`.
- `NestedFilter::Map` assoc type becomes `NestedFilter::MaybeTyCtxt`,
because it's always `!` or `TyCtxt`.
- `Visitor::nested_visit_map` becomes `Visitor::maybe_tcx`.
I deliberately made the new trait and associated type names different to
avoid the old `type Map: Map` situation, which I found confusing. We now
have `type MaybeTyCtxt: HirTyCtxt`.
