https://github.com/rust-lang/rust/issues/133150
This is more likely to be intended as an intra-doc link than it is to be
intended as a refdef. If a refdef is intended, it does not need to be
nested within a list item.
```markdown
- [`LONG_INTRA_DOC_LINK`]: this
looks like an intra-doc link,
but is actually a refdef.
The first line will seem to
disappear when rendered as HTML.
```
> - [`LONG_INTRA_DOC_LINK`]: this
> looks like an intra-doc link,
> but is actually a refdef.
> The first line will seem to
> disappear when rendered as HTML.
changelog: [`doc_nested_refdefs`]: add suspicious lint for link def at
start of list items and block quotes
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 updates the documentation after #13694. It is not based on that PR
chain and can be merged independently, but should be merged after that
PR.
This is partly pulled from #12762, but removing the Josh parts.
This includes instructions on how to publish `clippy_utils`.
Closes https://github.com/rust-lang/rust-clippy/issues/13556 (yes, this
is the final PR 🙂)
r? @blyxyas
changelog: `clippy_utils` is now published to crates.io
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
This is more likely to be intended as an intra-doc link than it is
to be intended as a refdef. If a refdef is intended, it does not
need to be nested within a list item or quote.
```markdown
- [`LONG_INTRA_DOC_LINK`]: this
looks like an intra-doc link,
but is actually a refdef.
The first line will seem to
disappear when rendered as HTML.
```
`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
changelog: [`trait_duplication_in_bounds`]: trigger on duplicate const
associated constraint as well
~~The first commit is part of #13722 which must be merged first.~~
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.
