- only mention the type once
- put types in backticks
- only highlight the method name in the suggestion
- removes the need for a snippet
- makes for finer diffs (seen through `cargo dev lint`)
While working on rust-lang/rust-clippy#16368, I found that this function
doesn't work correctly, presumably because the author was befuddled with
the negation.
r? @samueltardieu
---
changelog: none
in `LimitStack::pop_atr` always call `stack.pop()`.
It used to only be called inside a `debug_assert!` so the stack was not
popped in release builds.
Running `TESTNAME=cognitive_complexity cargo uitest --release` used to
print
```
error: there was 1 unmatched diagnostic
--> tests/ui/cognitive_complexity.rs:121:4
|
121 | fn bloo() {
| ^^^^ Error[clippy::cognitive_complexity]: the function has a cognitive complexity
of (2/1)
|
```
The first commit adds to the ui test, which also fails in release, the
2nd commit fixes the tests.
changelog: [`cognitive_complexity`]: fix attribute stack not popping in
release builds
`Duration::from_mins` and `Duration::from_hours` where [recently
stabilized](https://github.com/rust-lang/rust/issues/140881) in Rust
1.91.0.
In our codebase we often times have things like
```rust
Duration::from_secs(5 * 60);
// Since Rust 1.91.0 one can use
Duration::from_mins(5)
```
During the Rust 1.91.0 bump I noticed we can finally switch to
`Duration::from_mins(5)`, but many users might not be aware of this. I
started manually updating the places, but halfway through I figured
"Can't a lint do this for me?", so I added exactly that in this PR. It
does it for all stabilized `from_XXX` time units.
changelog: Add new [`duration_suboptimal_units`] lint
Closesrust-lang/rust-clippy#16335
The `LimitStack::pop_attrs` function used to pop from the stack in
`debug_assert_eq!` and check the value. The `pop` operation was therefore
only executed in debug builds, leading to an unbalanced stack in
release builds when attributes were present.
This change ensures the `pop` operation is always executed, by moving
it out of the debug-only assertion. The assertion is kept for debug
builds.
changelog: fix unbalanced stack in attributes
changelog: [`unnecessary_sort_by`]: respect applicability reduction due
to `Sugg`
changelog: [`unnecessary_sort_by`]: don't lint if `std` or `core` are
required for a suggestion but unavailable
The previous fix only handled `String`+`str`.
changelog: [`arithmetic_side_effects`]: do not warn on `String` +
`String`
Fixesrust-lang/rust-clippy#14054 (for good hopefully)
The iterator never loops when the closure used in, e.g., `.any()`,
panics, not when it diverges as a regular `return` lets the iterator
continue.
changelog: [`never_loop`]: do not consider `return` as preventing the
iterator from looping
Fixesrust-lang/rust-clippy#16363
r? @Jarcho
### Description
I updated the `useless_conversion` lint to stop applying adjustment
prefixes once it reaches the final target type.
Previously, the lint would continue applying adjustments even after the
type requirements were met, which often resulted in over-borrowed
suggestions like `&**y`. By breaking the loop early once the target type
is reached, we now emit the minimal, idiomatic suggestion (e.g., `*y`).
fixesrust-lang/rust-clippy#14847
### Test Plan
I added a targeted UI regression test: `tests/ui/useless_conversion.rs`.
This covers `.into_iter()` usage on nested slice references (`&&[T]`)
and verifies that Clippy now suggests `*items` instead of the previous
incorrect suggestion.
### Checklist
- [x] Added passing UI tests (including committed `.stderr` file)
- [x] `cargo test` passes locally
- [x] Run `cargo dev fmt`
[lint_naming]:
https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
---
changelog: [`useless_conversion`]: refine `.into_iter()` suggestions to
stop at the final target type (fixing over-borrowed suggestions like
`&**y`)
Fixesrust-lang/rust-clippy#16150 , do not error when importing
anonymously using an underscore.
In the issue it is suggested that perhaps there could be a flag to
enable/disable this new behavior, but I don't see a strong case for
disallowing "as _" when a rename was specified.
Please let me know if you think that flag would be useful and I can
implement that on top.
```
changelog: [`missing_enforced_import_rename`]: do not enforce renaming consistency in the case "import ... as _;"
```
