Fixes#13748
Diagnostic for that issue with this change:
```
warning: spawned process is not `wait()`ed on in all code paths
--> x.rs:167:19
|
167 | let mut cmd = cmd.unwrap();
| ^^^^^^^^^^^^
|
note: no `wait()` call exists on the code path to this early return
--> x.rs:178:47
|
178 | std::io::ErrorKind::BrokenPipe => return Some(0),
| ^^^^^^^^^^^^^^
note: `wait()` call exists, but it is unreachable due to the early return
--> x.rs:185:10
|
185 | Some(cmd.wait().unwrap().code().unwrap()) // <-- wait()!
| ^^^
= help: consider calling `.wait()` in all code paths
= note: not doing so might leave behind zombie processes
= note: see https://doc.rust-lang.org/stable/std/process/struct.Child.html#warning
```
Instead of saying "wait() is **never** called", it now says it's not
called by all code paths and points out the early return in particular.
changelog: none
The new cases are the application of `Into::into` or `From::from`
through the following functions with no effect:
- `Option::map()`
- `Result::map()` and `Result::map_err()`
- `ControlFlow::map_break()` and `ControlFlow::map_err()`
- `Iterator::map()`
changelog: [`useless_conversion`]: detect useless calls to `Into::into`
and `From::from` application through `map*` methods
Closes#13574
Make sure that `needless_match` doesn't simplify:
```
if let Some(_) = a() {
// ..
} else let Some(_) = b() {
// ..
}
```
to:
```
a()
```
changelog: [`needless_match`]: Fix false-positive on if lets
Fixes https://github.com/rust-lang/rust-clippy/issues/10780
We correctly no longer give a warning when a closure is passed to a
method, where one of the arguments to that method uses the variable
which would be shadowed by an argument to that closure.
Uses is defined loosely as any expression used in the calling expression
mentions the shadowee binding (except for the closure itself):
```rust
#![deny(clippy::shadow_unrelated)]
let x = Some(1);
let y = x.map(|x| x + 1);
```
will now succeed.
See https://github.com/linebender/xilem/pull/745 - without this change,
all of the `expect(shadow_unrelated)` in the repository are met; with
it, none of them are.
changelog: [`shadow_unrelated`]: Don't treat closures arguments as
unrelated when the calling function uses them
This is in honor of `@bors` who is no longer used in this repo. I've
been saving this poem for a special PR, but it just seems fitting to use
it now:
Bors the bot,
Handsome and strong!
Will you go with me,
To prom?
---
### The cat of this release is Abu nominated by @jdonszelmann :
<img height=700
src="https://github.com/user-attachments/assets/414f24a1-8bbf-4fed-bcbc-acc5ca6a1353"
alt="The cats of this Clippy release" />
Cats for the next release can be nominated in the comments :D
---
changelog: none
`clap-3.1.6` was not compiling on the rustc-perf benchmarks because of
this lint. Also, the user could not allow the lint on the macro itself
because it was checking Exprs, not whatever the input of `bitflags!` is.
```
error: &-masking with zero
--> src/build/arg_settings.rs:197:1
|
(#[allow] here)
197 | / bitflags! {
198 | | struct Flags: u32 {
199 | | const REQUIRED ...
200 | | const MULTIPLE_OCC ...
... |
226 | | }
227 | | }
| |_^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#bad_bit_mask
= note: this error originates in the macro `__impl_bitflags` which comes from the expansion of the macro `bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)
```
changelog: [`bad_bit_mask`]: Fix FP on procedural macros
This should address #13099 for the `derivable_impls` test. As I've not
contributed to clippy before, I'd like to make sure i'm on the right
track before doing more :)
changelog: [`derivable_impls`]: Use multipart_suggestion to aggregate
feedback
Inline ExprPrecedence::order into Expr::precedence
The representation of expression precedence in rustc_ast has been an obstacle to further improvements in the pretty-printer (continuing from #119105 and #119427).
Previously the operation of *"does this expression have lower precedence than that one"* (relevant for parenthesis insertion in macro-generated syntax trees) consisted of 3 steps:
1. Convert `Expr` to `ExprPrecedence` using `.precedence()`
2. Convert `ExprPrecedence` to `i8` using `.order()`
3. Compare using `<`
As far as I can guess, the reason for the separation between `precedence()` and `order()` was so that both `rustc_ast::Expr` and `rustc_hir::Expr` could convert as straightforwardly as possible to the same `ExprPrecedence` enum, and then the more finicky logic performed by `order` could be present just once.
The mapping between `Expr` and `ExprPrecedence` was intended to be as straightforward as possible:
```rust
match self.kind {
ExprKind::Closure(..) => ExprPrecedence::Closure,
...
}
```
although there were exceptions of both many-to-one, and one-to-many:
```rust
ExprKind::Underscore => ExprPrecedence::Path,
ExprKind::Path(..) => ExprPrecedence::Path,
...
ExprKind::Match(_, _, MatchKind::Prefix) => ExprPrecedence::Match,
ExprKind::Match(_, _, MatchKind::Postfix) => ExprPrecedence::PostfixMatch,
```
Where the nature of `ExprPrecedence` becomes problematic is when a single expression kind might be associated with multiple different precedence levels depending on context (outside the expression) and contents (inside the expression). For example consider what is the precedence of an ExprKind::Closure `$closure`. Well, on the left-hand side of a binary operator it would need parentheses in order to avoid the trailing binary operator being absorbed into the closure body: `($closure) + Rhs`, so the precedence is something lower than that of `+`. But on the right-hand side of a binary operator, a closure is just a straightforward prefix expression like a unary op, which is a relatively high precedence level, higher than binops but lower than method calls: `Lhs + $closure` is fine without parens but `($closure).method()` needs them. But as a third case, if the closure contains an explicit return type, then the precedence is an even higher level than that, never needing parenthesization even in a binop left-hand side or method call: `|| -> bool { false } + Rhs` or `|| -> bool { false }.method()`.
You can see that trying to capture all of this resolution about expressions into `ExprPrecedence` violates the intention of `ExprPrecedence` being a straightforward one-to-one correspondence from each AST and HIR `ExprKind` variant. It would be possible to attempt that by doing stuff like `ExprPrecedence::Closure(Side::Leading, ReturnType::No)`, but I don't foresee the original envisioned benefit of the `precedence()`/`order()` distinction being retained in this approach. Instead I want to move toward a model that Syn has been using successfully. In Syn, there is a Precedence enum but it differs from rustc in the following ways:
- There are [relatively few variants](https://github.com/dtolnay/syn/blob/2.0.87/src/precedence.rs#L11-L47) compared to rustc's `ExprPrecedence`. For example there is no distinction at the precedence level between returns and closures, or between loops and method calls.
- We distinguish between [leading](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L293) and [trailing](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L309) precedence, taking into account an expression's context such as what token follows it (for various syntactic bail-outs in Rust's grammar, like ambiguities around break-with-value) and how it relates to operators from the surrounding syntax tree.
- There are no hardcoded mysterious integer quantities like rustc's `PREC_CLOSURE = -40`. All precedence comparisons are performed via PartialOrd on a C-like enum.
This PR is just a first step in these changes. As you can tell from Syn, I definitely think there is value in having a dedicated type to represent precedence, instead of what `order()` is doing with `i8`. But that is a whole separate adventure because rustc_ast doesn't even agree consistently on `i8` being the type for precedence order; `AssocOp::precedence` instead uses `usize` and there are casts in both directions. It is likely that a type called `ExprPrecedence` will re-appear, but it will look substantially different from the one that existed before this PR.
It's becoming more and more common to see people including markdown
files in their code using `doc = include_str!("...")`, which is great.
However, often there is no condition on this include, which is not great
because it slows down compilation and might trigger recompilation if
these files are updated.
This lint aims at fixing this situation.
changelog: Add new lint `doc_include_without_cfg`
Currently this only provides the feature to auto-update the versions in the
`Cargo.toml` files. With the move to Josh, a command to get beta and stable
release commits will be added.
changelog: [`missing_safety_doc`]: accept uppercase "SAFETY"
In [Oxc](https://github.com/oxc-project/oxc)'s codebase, we try to draw
attention as clearly as possible to the safety constraints of unsafe
code by including an uppercase `# SAFETY` doc comment.
Clippy's `missing_safety_doc` lint does not recognise "SAFETY" in upper
case, so we also need to include `#[expect(clippy::missing_safety_doc)]`
on every unsafe function, to avoid a false positive. Unfortunately this
defeats the purpose of the lint, as if someone later removes the safety
docs, the lint rule does not trigger.
I don't know how common this style of documenting unsafe functions is,
but I don't imagine also supporting `# SAFETY` would disturb other users
who prefer `# Safety`.
the behavior of the type system not only depends on the current
assumptions, but also the currentnphase of the compiler. This is
mostly necessary as we need to decide whether and how to reveal
opaque types. We track this via the `TypingMode`.
