changelog: [`manual_ok_err`]: new lint
Detect manual implementations of `.ok()` or `.err()`, as in
```rust
let a = match func() {
Ok(v) => Some(v),
Err(_) => None,
};
let b = if let Err(v) = func() {
Some(v)
} else {
None
};
```
which can be replaced by
```rust
let a = func().ok();
let b = func().err();
```
This pattern was detected in the wild in the Rust reimplementation of
coreutils:
https://github.com/uutils/coreutils/pull/6886#pullrequestreview-2465160137
Some lifetimes in function return types are not bound to concrete
content and can be set arbitrarily. Clippy should not propose to replace
them by the default `'_` lifetime if such a lifetime cannot be
determined unambigously.
I added a field to the `LifetimeChecker` and `Usage` to flag lifetimes
that cannot be replaced by default ones, but it feels a bit hacky.
Fix#13923
changelog: [`needless_lifetimes`]: remove false positives by checking
that lifetimes can indeed be elided
Fixes#13913 .
changelog: [`manual_is_ascii_check`]: fix type suggestions for
references
Previously it only derived `char` and `u8` types, now it should always
annotate the lambda parameter with the correct type (e.g. `&char`).
I'm quite new to Rust and this is my first contact with clippy, so I'm
open for suggetions :)
Some lifetimes in function return types are not bound to concrete
content and can be set arbitrarily. Clippy should not propose to replace
them by the default `'_` lifetime if such a lifetime cannot be
determined unambigously.
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#13692.
If the `vec!` macro call contains comments, we should not provide
suggestions and let users handle it however they see fit.
changelog: Only emit `useless_vec` suggestion if the macro does not
contain code comments
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.
I [recently realized that `.last()` might not call `next_back()` when it
is
available](https://qsantos.fr/2025/01/01/rust-gotcha-last-on-doubleendediterator/).
Although the implementor could make sure to implement `last()` to do so,
this is not what will happen by default. As a result, I think it is
useful to add a lint to promote using `.next_back()` over `.last()` on
`DoubleEndedIterator`.
If this is merged, we might want to close #1822.
changelog: [`double_ended_iterator_last`]: Add lint for calling
`Iterator::last()` on `DoubleEndedIterator`
close#13781
The `slow_vector_initialization` lint currently only suggests using the
`vec!` macro with size, but it does not suggest removing the `resize`
method call.
changelog: [`slow_vector_initialization`]: improve
`slow_vector_initialization` suggestion
In this case, the lint can be triggered as well as `is_empty()` will be
found on the target type.
One such case was found in Clippy sources (first commit)
changelog: [`len_zero`]: trigger if deref target implements `is_empty()`
Close#13861
Using `lifetime.ident.name` in suggestions will not output the raw
modifier. For example, `'r#struct` will be rendered as `'struct` which
would be incorrect.
Fix#13899
changelog: [`needless_arbitrary_self_type`]: use the raw lifetime name
in suggestions
Using `lifetime.ident.name` in suggestions will not output the raw
modifier. For example, `'r#struct` will be rendered as `'struct` which
would be incorrect.
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.
Also, simplify boolean shortcut expression, and ensure that
applicability is properly applied, as it was ignored and
`MachineApplicable` was always used.
changelog: [`borrow_as_ptr`]: do not remove required parentheses in
autofix suggestion
Close#13882
This PR just makes sure that we exit the function before getting an ICE
and adds a regression test. Related to #12979. We would need to keep
researching the issue, but as the ICEing code isn't that complicated,
getting a hotfix into nightly is urgent.
changelog:[`borrow_interior_mutable_const`] Fix ICE #12979
Fixes#13862
`missing_headers::check` is sometimes called from outside of a body
(specifically, from `check_attributes`, where the LateContext's ParamEnv
is not yet properly initialized for that item). Using that empty
ParamEnv for trait solving things from within the body can then lead to
various ICEs, like the linked issue where we have a const generic
parameter `DMA_INST` without a `ConstArgHasType` bound in the ParamEnv
so the const parameter has no type, which is normally not supposed to
happen.
We have the item's DefId so we can just get its ParamEnv/TypingEnv from
there, and using that one for trait solving should be safe.
changelog: none
Convert the ICE reported in #12979 into a false negative.
We prefer a false negative to a ICE (because the ICE could
still affect the user even when not activating the lint).
