`manual_ok_or` covers the same case that were covered by
`option_map_or_err_ok` which is not deprecated. The latter was in the
"style" category. Also, the lint is machine applicable, and leads to
shorter and more readable code, so "style" is appropriate.
The only difference is that the η-expanded form of `Result::Ok()` was
not covered by `option_map_or_err_ok` while it is by `manual_ok_or`, so
the category change may expose some new occurrences.
Without this check, the lint would suggest that
```rust
match test {
true if option == 5 => 10,
_ => 1,
};
```
is replaced by `if test { 10 } else { 1 }`.
changelog: [`match_bool`]: omit suggestion when guards are present in
`match` expression
Before edition 2024, some temporaries used in scrutinees of a `match`
used as the last expression of a block may outlive some referenced local
variables. Prevent those cases from happening by checking that alive
temporaries with significant drop do have a static lifetime.
The check is performed only for edition 2021 and earlier, and for the
last statement if it would become the last expression of the block.
changelog: [`unnecessary_semicolon`]: prevent borrow errors in editions
lower than 2024
r? @y21
Using `Vec::extend(std::iter::repeat_n(item, N))` allows to use the more
natural number of elements to add `N`, as is probably done in the
original loop, instead of computing the difference between the existing
number of elements and the wanted one.
Before MSRV 1.82, the older suggestion to use `Vec::resize()` is still
issued.
Inspired by #6156 (which predates `repeat_n()`).
changelog: [`same_item_push`]: recommend using `Vec::extend()` to extend
a vector
Before edition 2024, some temporaries used in scrutinees in a `match`
used as the last expression of a block may outlive some referenced
local variables. Prevent those cases from happening by checking that
alive temporaries with significant drop do have a static lifetime.
The check is performed only for edition 2021 and earlier, and for the
last statement if it would become the last expression of the block.
- The lint no longer triggers if one of the operands in the boolean
expression comes from a macro expansion.
- Parenthesis are now removed inside the generated block if they are no
longer necessary.
- Error markers have been added.
changelog: [`short_circuit_statement`]: better handling of macros and
better looking suggestions
- The lint no longer triggers if the expression comes from macro
expansion
- Parenthesis are now removed inside the generated block if they are no
longer necessary.
This PR fixes an issue with the `significant_drop_in_scrutinee`, where
the lint generates invalid Rust syntax when suggesting fixes for match
expressions that are part of larger expressions, such as in assignment
contexts. For example:
```rust
let mutex = Mutex::new(State {});
let _ = match mutex.lock().unwrap().foo() {
true => 0,
false => 1,
};
```
would suggest:
```rust
let _ = let value = mutex.lock().unwrap().foo();
match value {
```
With this PR, it now suggests:
```rust
let value = mutex.lock().unwrap().foo();
let _ = match value {
```
closes: #13986
changelog: [`significant_drop_in_scrutinee`] Fix incorrect suggestion
for `significant_drop_in_scrutinee` lint in expression context
Without this check, the lint would suggest that
```rust
match test {
true if option == 5 => 10,
_ => 1,
};
```
is replaced by `if test { 10 } else { 1 }`.
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
This PR changes literal_string_with_formatting_args category from
`suspicious` to `nursery` since there are thousands of false positive on
GitHub.
Closes#13989 since it's no longer problematic with such false positive
with ~~`pedantic`~~ `nursery` category.
changelog: [`literal_string_with_formatting_args` ] change category to
`nursery` from `suspicious`
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.
1.83 stabilized `CONST_MUT_REFS`, also allowing for `const fn` to mutate
through mutable references. This ensures `missing_const_for_fn` is
emitted for those cases.
changelog: [`missing_const_for_fn`]: Now suggests marking some functions
taking mutable references `const`
Using `Vec::extend(std::iter::repeat_n(item, N))` allows to use the more
natural number of elements to add `N`, as is probably done in the original
loop, instead of computing the difference between the existing number of
elements and the wanted one.
Before MSRV 1.82, the older suggestion to use `Vec::resize()` is still
issued.
I'll take a short break from auto assignments. My last few weeks have
been busy and I feel like getting my inbox back in order and taking a
short breather will be the best for me.
I still plan to review the PRs I'm currently assigned to and writing the
changelogs.
Jup that's it, have a good day, who ever is reading this =^.^=
changelog: none
changelog: [`useless-nonzero-new_unchecked`]: new lint
Close#13991
### What it does
Checks for `NonZero*::new_unchecked(<literal>)` being used in a `const`
context.
### Why is this bad?
Using `NonZero*::new_unchecked()` is an `unsafe` function and requires
an `unsafe` context. When used with an
integer literal in a `const` context, `NonZero*::new().unwrap()` will
provide the same result with identical
runtime performances while not requiring `unsafe`.
### Example
```no_run
const PLAYERS: NonZeroUsize = unsafe { NonZeroUsize::new_unchecked(3) };
```
Use instead:
```no_run
const PLAYERS: NonZeroUsize = NonZeroUsize::new(3).unwrap();
```
Commit 9ef6e2199c introduced a check to
ensure that Clippy doesn't consider a lifetime present in an explicit
self types as being the default for an elided output lifetime. For
example, elision did not work in the case like:
```rust
fn func(self: &Rc<Self>, &str) -> &str { … }
```
Since Rust 1.81.0, the lifetime in the self type is now considered the
default for elision. Elision should then be suggested when appropriate.
changelog: [`needless_lifetimes`]: suggest elision of lifetimes present
in explicit self types as well
r? @Alexendoo
because of #8278
Temporaries created inside the expansion of `.await` will be dropped and
need no checking. Looking inside the expansion will trigger false
positives.
changelog: [`significant_drop_in_scrutinee`]: do not falsely warn for
temporaries created by `.await` expansion
Fix#13927
Commit 9ef6e2199c introduced a check to
ensure that Clippy doesn't consider a lifetime present in an explicit
self type as being the default for an elided output lifetime. For
example, elision did not work in the case like:
```rust
fn func(self: &Rc<Self>, &str) -> &str { … }
```
Since Rust 1.81.0, the lifetime in the self type is now considered
the default for elision. Elision should then be suggested when
appropriate.
