changelog: [`expl_impl_clone_on_copy`]: honor `allow`/`expect`
attributes on both the type declaration and the `impl`
Fixesrust-lang/rust-clippy#15842
r? @blyxyas
changelog: [`unnecessary_option_map_or_else`]: Added lint
unnecessary_option_map_or_else. As suggested in the issue description,
the implementation takes as reference the issue
rust-lang/rust-clippy#7328. The tests for lints `option_if_let_else` and
`or_fun_call` needed to be adjusted to comply with new lint.
fixesrust-lang/rust-clippy#14588
Fixesrust-lang/rust-clippy#15805
ICE bisects to 9457d640b7, which handles the span incorrectly when part
of the path originates from internal declarative macro.
changelog: none
Volatile reads and writes to non-primitive types are not well-defined,
and can cause problems.
Fixesrust-lang/rust-clippy#15529
changelog: [`volatile_composites`]: Lint when read/write_volatile is
used on composite types
(structs, arrays, etc) as their semantics are not well defined.
now lints on
```rs
let mut x = [1,2,3].into_iter();
loop {
let Some(x) = x.next() else { break };
dbg!(x);
}
```
```
changelog: [`while_let_loop`]: extend to lint on `let else`
```
First commit treats all constants containing a macro call as non-local
and renames `eval_simple` to be a little clearer.
Second commit removes `CoreConstant` and treats most of them as though
they were local. A couple of the constants like `usize::MAX` are treated
as non-local as different targets may have different values.
`const_is_empty` will now ignore non-local constants since there's no
guarantee that they are the same across all targets/features/versions.
The third commit just changes some `eval` calls to `eval_local`. Most of
these were style lints which shouldn't be assuming the value of a
constant won't ever change.
changelog: none
With this and rust-lang/rust-clippy#13084 our toml version will be
pushed to `0.9.7`. This is different from rustc's version, but the
changes in rust-lang/rust-clippy#13084 already require an incompatible
version.
The `serde` feature is also removed since it was only used in one spot
with a mostly trivial replacement.
changelog: none
Starting with Rust version 1.82.0, the compiler generates similar code
with and without the `with_ref` cfg:
```rust
fn f(x: impl IntoIterator<Item = String>) {
for y in x { println!("{y}"); }
}
fn main() {
#[cfg(with_ref)]
let a = ["foo", "bar"].iter().map(|&s| s.to_string());
#[cfg(not(with_ref))]
let a = ["foo", "bar"].iter().map(|s| s.to_string());
f(a);
}
```
The generated code is strictly identical with `-O`, and identical modulo
some minor reordering without.
changelog: [`inefficient_to_string`]: do not trigger for Rust ≥ 1.82.0
Starting with Rust version 1.82.0, the compiler generates similar code with
and without the `with_ref` cfg:
```rust
fn f(x: impl IntoIterator<Item = String>) {
for y in x { println!("{y}"); }
}
fn main() {
#[cfg(with_ref)]
let a = ["foo", "bar"].iter().map(|&s| s.to_string());
#[cfg(not(with_ref))]
let a = ["foo", "bar"].iter().map(|s| s.to_string());
f(a);
}
```
The generated code is strictly identical with `-O`, and identical modulo
some minor reordering without.
This might be due to a low edition (< 2024) or too low a MSRV. In this
case, we will suggest only `match`.
Fixesrust-lang/rust-clippy#15744
changelog: [`unnecessary_unwrap`]: do not suggest using `if let` chains
if this is not supported with the current edition or MSRV
changelog:[`collapsible_if`]: Do not suggest using `if let` if this is
not supported with the current edition or MSRV
The issue that I saw made me rethink the lint design by quite a lot, so
I decided to include that change in this PR
fixesrust-lang/rust-clippy#9000
changelog: [`double_parens`]: add structured suggestions
changelog: [`double_parens`]: fix FP when macros are involved
I.e, instead of constructing a whole new `LetStmt` to replace the old
one, suggest to only change the part of the `LetStmt` that we don't
like. This makes the suggestion less likely to introduce spurious
changes, but also makes the diagnostic much nicer imo.
Fixesrust-lang/rust-clippy#15771 by not adding a semicolon that the
initial `LetStmt` didn't have
Fixesrust-lang/rust-clippy#15784 by using the `init.span` with the
correct `SyntaxContext`
changelog: [`let_unit_value`]: don't add spurious semicolon
changelog: [`let_unit_value`]: don't mangle macro calls
This PR:
- adds structured suggestions to all 3 lint scenarios
- adds more examples of linted patterns, and recommended fixes
- moves some test cases to `_unfixable.rs`, to allow running rustfix on
the main file
- stops the lint from firing multiple times on types like `&mut &mut
&mut T`
Open questions:
- I'd like to add a note explaining why chained `&mut` are useless.. but
can't really come up with something consice. I very much don't like the
one in the docs -- it's a bit too condescending imo.
- see comments in the diff for more
I do realize that the PR ended up being quite wide-scoped, but that's
primarily because once I added structured suggestions to one of the lint
cases, `ui_test` started complaining about warnings remaining after the
rustfix run, which of course had to with the fact that the other two
lint cases didn't actually fix the code they linted, only warned. I
_guess_ `ui_test` could be smarter about this, by understanding that if
a warning was created without a suggestion, then that warning will still
remain in the fixed file. But oh well.
changelog: [`mut_mut`]: add structured suggestions, improve docs
fixesrust-lang/rust-clippy#13021
