Changelog for Rust 1.65
Roses are red,
violets are blue,
another 6 weeks,
another changelog, yahoo!
This did not rhyme,
luckily, not a crime.
I want to say something smart,
but I am out of time.
---
Note for the reviewer. This PR is written, as if Rust was already released on 2022-11-03. Please review the changes and approve if you agree, but only merge it after the release. :)
---
changelog: none
Improve `needless_lifetimes`
This PR makes the following improvements to `needless_lifetimes`.
* It fixes the following false negative, where `foo` is flagged but `bar` is not:
```rust
fn foo<'a>(x: &'a u8, y: &'_ u8) {}
fn bar<'a>(x: &'a u8, y: &'_ u8, z: &'_ u8) {}
```
* It flags more cases, generally. Previously, `needless_borrow` required *all* lifetimes to be used only once. With the changes, individual lifetimes are flagged for being used only once, even if not all lifetimes are.
* Finally, it tries to produce more clear error messages.
changelog: fix `needless_lifetimes` false negative involving functions with multiple unnamed lifetimes
changelog: in `needless_lifetimes`, flag individual lifetimes used only once, rather than require all lifetimes to be used only once
changelog: in `needless_lifetimes`, emit "replace with `'_`" warnings only when applicable, and point to a generic argument
Add lint for confusing use of `^` instead of `.pow`
fixes#4205
Adds a lint named [`confusing_xor_and_pow`], it warns the user when `a ^ b` is used as the `.pow()` function, it doesn't warn for Hex, Binary... etc.
---
changelog: New lint: [`confusing_xor_and_pow`]
Warn when `clippy::restriction` is enabled via the command line
Currently it catches `#![warn(clippy::restriction)]`, it'll now catch `-W clippy::restriction` from the CLI. Also tweaks the message slightly
changelog: [`blanket_clippy_restriction_lints`]: Warn when `clippy::restriction` is enabled via the command line
fix `undocumented-unsafe-blocks` false positive
This fixes#9142 by iterating over the parent nodes as long as within a block, expression, statement, local, const or static.
---
changelog: none
fix the `string-extend-chars` suggestion on slice
This adds the missing `&` to the suggestion if the target is a `str` slice (e.g. extending with `"foo"[..].chars()`).
This closes#9735.
---
changelog: fix the `string-extend-chars` suggestion for `str` slices
Ensure new_ret_no_self is not fired if impl Trait<Self> is returned.
Fix#7344: ensure new_ret_no_self is not fired if `impl Trait<Self>` is returned.
changelog: [`new_ret_no_self`]: No longer lints when `impl Trait<Self>` is returned
[`use_self`] fix suggestion when full path to struct was given
Previously the following wrong suggestion was given
```rust
impl Error for std::fmt::Error {
fn custom<T: std::fmt::Display>(_msg: T) -> Self {
- std::fmt::Error // Should lint
+ Self::Error // Should lint
}
}
```
Also remove known problem line related to #4140 since it's been closed, and refactor the lint
changelog: [`use_self`] fix suggestion when full path to struct was given
`question_mark` don't lint on `if let Err` with `else`
cc #9518
AFAICT the only time this would be a valid suggestion is the rather esoteric
```rust
let _ = if let Err(e) = x {
return Err(e);
} else {
// no side effects
x.unwrap()
}
```
which doesn't seem worth checking to me. Please correct me if I'm missing something.
changelog: [`question_mark`] don't lint on `if let Err` with `else`
move `UNINLINED_FORMAT_ARGS` to pedantic
As discussed in zulip, we are moving this lint to pedantic to be backported
changelog: [`UNINLINED_FORMAT_ARGS`]: move to pedantic
Fix `needless_borrow` false positive
The PR fixes the false positive exposed by `@BusyJay's` example in: https://github.com/rust-lang/rust-clippy/issues/9111#issuecomment-1277114280
The current approach is described in https://github.com/rust-lang/rust-clippy/pull/9674#issuecomment-1289294201 and https://github.com/rust-lang/rust-clippy/pull/9674#issuecomment-1292225232.
The original approach appears below.
---
The proposed fix is to flag only "simple" trait implementations involving references, a concept
that I introduce next.
Intuitively, a trait implementation is "simple" if all it does is dereference and apply the trait
implementation of a type named by a type parameter. `AsRef` provides a good example of a simple
implementation: https://doc.rust-lang.org/std/convert/trait.AsRef.html#impl-AsRef%3CU%3E-for-%26T
We can make this idea more precise as follows. Given a trait implementation, first determine
whether the implementation is "used defined." If so, then examine its nested obligations.
Consider the implementation simple if-and-only-if:
- there is at least one nested obligation for the same trait
- for each type `X` in the nested obligation's substitution, either `X` is the same as that of
the original obligation's substitution, or the original type is `&X`
For example, the following implementation from `@BusyJay's` example is "complex" (i.e., not simple)
because it produces no nested obligations:
```rust
impl<'a> Extend<&'a u8> for A { ... }
```
On the other hand, the following slightly modified implementation is simple, because it produces
a nested obligation for `Extend<X>`:
```rust
impl<'a, X> Extend<&'a X> for A where A: Extend<X> { ... }
```
How does flagging only simple implementations help? One way of interpreting the false positive in
`@BusyJay's` example is that it separates a reference from a concrete type. Doing so turns a
successful type inference into a failing one. By flagging only simple implementations, we
separate references from type variables only, thereby eliminating this class of false positives.
Note that `Deref` is a special case, as the obligations generated for it already involve the
underlying type.
r? `@Jarcho` (Sorry to keep pinging you with `needless_borrow` stuff. But my impression is no one knows this code better than you.)
changelog: fix `needless_borrow` false positive
Previously the following wrong suggestion was given
```rust
impl Error for std::fmt::Error {
fn custom<T: std::fmt::Display>(_msg: T) -> Self {
- std::fmt::Error // Should lint
+ Self::Error // Should lint
}
}
```
Also remove known problem line related to #4140 since it's been closed, and refactor the lint
Trevor Arjeski
