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
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.
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`
take 2
open up coroutines
tweak the wordings
the lint works up until 2021
We were missing one case, for ADTs, which was
causing `Result` to yield incorrect results.
only include field spans with significant types
deduplicate and eliminate field spans
switch to emit spans to impl Drops
Co-authored-by: Niko Matsakis <nikomat@amazon.com>
collect drops instead of taking liveness diff
apply some suggestions and add explantory notes
small fix on the cache
let the query recurse through coroutine
new suggestion format with extracted variable name
fine-tune the drop span and messages
bugfix on runtime borrows
tweak message wording
filter out ecosystem types earlier
apply suggestions
clippy
check lint level at session level
further restrict applicability of the lint
translate bid into nop for stable mir
detect cycle in type structure
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.
Currently this only provides the feature to auto-update the nightly version in
the `rust-toolchain` file and the `clippy_utils/README.md` file. The actual sync
to and from the Rust repo will be added with the move to Josh.
On arm64 I get
```
error[E0570]: `"vectorcall"` is not a supported ABI for the current target
```
We don't seem to be doing any ABI specific handling so it seems fine to
just remove this one since there are other tests
changelog: none
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`.
There was some dependence between the different subcommands of clippy_dev. And
this dependence will increased with the introduction of the sync and release
subcommands. This moves the common functions to a `utils` module, to decouple
the other modules.
