Conversation
"Missing" patterns are possible in bare fn types (`fn f(u32)`) and
similar places. Currently these are represented in the AST with
`ast::PatKind::Ident` with no `by_ref`, no `mut`, an empty ident, and no
sub-pattern. This flows through to `{hir,thir}::PatKind::Binding` for
HIR and THIR.
This is a bit nasty. It's very non-obvious, and easy to forget to check
for the exceptional empty identifier case.
This commit adds a new variant, `PatKind::Missing`, to do it properly.
The process I followed:
- Add a `Missing` variant to `{ast,hir,thir}::PatKind`.
- Chang `parse_param_general` to produce `ast::PatKind::Missing`
instead of `ast::PatKind::Missing`.
- Look through `kw::Empty` occurrences to find functions where an
existing empty ident check needs replacing with a `PatKind::Missing`
check: `print_param`, `check_trait_item`, `is_named_param`.
- Add a `PatKind::Missing => unreachable!(),` arm to every exhaustive
match identified by the compiler.
- Find which arms are actually reachable by running the test suite,
changing them to something appropriate, usually by looking at what
would happen to a `PatKind::Ident`/`PatKind::Binding` with no ref, no
`mut`, an empty ident, and no subpattern.
Quite a few of the `unreachable!()` arms were never reached. This makes
sense because `PatKind::Missing` can't happen in every pattern, only
in places like bare fn tys and trait fn decls.
I also tried an alternative approach: modifying `ast::Param::pat` to
hold an `Option<P<Pat>>` instead of a `P<Pat>`, but that quickly turned
into a very large and painful change. Adding `PatKind::Missing` is much
easier.
In the AST, currently we use `BinOpKind` within `ExprKind::AssignOp` and `AssocOp::AssignOp`, even though this allows some nonsensical combinations. E.g. there is no `&&=` operator. Likewise for HIR and THIR. This commit introduces `AssignOpKind` which only includes the ten assignable operators, and uses it in `ExprKind::AssignOp` and `AssocOp::AssignOp`. (And does similar things for `hir::ExprKind` and `thir::ExprKind`.) This avoids the possibility of nonsensical combinations, as seen by the removal of the `bug!` case in `lang_item_for_binop`. The commit is mostly plumbing, including: - Adds an `impl From<AssignOpKind> for BinOpKind` (AST) and `impl From<AssignOp> for BinOp` (MIR/THIR). - `BinOpCategory` can now be created from both `BinOpKind` and `AssignOpKind`. - Replaces the `IsAssign` type with `Op`, which has more information and a few methods. - `suggest_swapping_lhs_and_rhs`: moves the condition to the call site, it's easier that way. - `check_expr_inner`: had to factor out some code into a separate method. I'm on the fence about whether avoiding the nonsensical combinations is worth the extra code.
Add new `PatKind::Missing` variants To avoid some ugly uses of `kw::Empty` when handling "missing" patterns, e.g. in bare fn tys. Helps with #137978. Details in the individual commits. r? ``@oli-obk``
…rpolated, r=petrochenkov Remove `Nonterminal` and `TokenKind::Interpolated` A third attempt at this; the first attempt was #96724 and the second was #114647. r? `@ghost`
By replacing them with `{Open,Close}{Param,Brace,Bracket,Invisible}`.
PR #137902 made `ast::TokenKind` more like `lexer::TokenKind` by
replacing the compound `BinOp{,Eq}(BinOpToken)` variants with fieldless
variants `Plus`, `Minus`, `Star`, etc. This commit does a similar thing
with delimiters. It also makes `ast::TokenKind` more similar to
`parser::TokenType`.
This requires a few new methods:
- `TokenKind::is_{,open_,close_}delim()` replace various kinds of
pattern matches.
- `Delimiter::as_{open,close}_token_kind` are used to convert
`Delimiter` values to `TokenKind`.
Despite these additions, it's a net reduction in lines of code. This is
because e.g. `token::OpenParen` is so much shorter than
`token::OpenDelim(Delimiter::Parenthesis)` that many multi-line forms
reduce to single line forms. And many places where the number of lines
doesn't change are still easier to read, just because the names are
shorter, e.g.:
```
- } else if self.token != token::CloseDelim(Delimiter::Brace) {
+ } else if self.token != token::CloseBrace {
```
Co-authored-by: est31 <est31@users.noreply.github.com>
apparently it doesn't really use the asm parsing at present, so this may work?
Keep the `P` constructor function for now, to minimize immediate churn. All the `into_inner` calls are removed, which is nice.
So they match the order of the parts in the source code, e.g.:
```
struct Foo<T, U> { t: T, u: U }
<-><----> <------------>
/ | \
ident generics variant_data
```
Reorder `ast::ItemKind::{Struct,Enum,Union}` fields.
So they match the order of the parts in the source code, e.g.:
```
struct Foo<T, U> { t: T, u: U }
<-><----> <------------>
/ | \
ident generics variant_data
```
r? `@fee1-dead`
Reduce `ast::ptr::P` to a typedef of `Box` As per the MCP at rust-lang/compiler-team#878. r? `@fee1-dead`
"{{root}}" is an internal-only name, and cannot appear in Rust code
being formatted.
Rollup of 9 pull requests Successful merges: - rust-lang/rust#142331 (Add `trim_prefix` and `trim_suffix` methods for both `slice` and `str` types.) - rust-lang/rust#142491 (Rework #[cold] attribute parser) - rust-lang/rust#142494 (Fix missing docs in `rustc_attr_parsing`) - rust-lang/rust#142495 (Better template for `#[repr]` attributes) - rust-lang/rust#142497 (Fix random failure when JS code is executed when the whole file was not read yet) - rust-lang/rust#142575 (Ensure copy* intrinsics also perform the static self-init checks) - rust-lang/rust#142650 (Refactor Translator) - rust-lang/rust#142713 (mbe: Refactor transcription) - rust-lang/rust#142755 (rustdoc: Remove `FormatRenderer::cache`) r? `@ghost` `@rustbot` modify labels: rollup
…iscross Implement parsing of pinned borrows This PR implements part of #130494. EDIT: It introduces `&pin mut $place` and `&pin const $place` as sugars for `std::pin::pin!($place)` and its shared reference equivalent, except that `$place` will not be moved when borrowing. The borrow check will be in charge of enforcing places cannot be moved or mutably borrowed since being pinned till dropped. ### Implementation steps: - [x] parse the `&pin mut $place` and `&pin const $place` syntaxes - [ ] borrowck of `&pin mut|const` - [ ] support autoref of `&pin mut|const` when needed
New const traits syntax This PR only affects the AST and doesn't actually change anything semantically. All occurrences of `~const` outside of libcore have been replaced by `[const]`. Within libcore we have to wait for rustfmt to be bumped in the bootstrap compiler. This will happen "automatically" (when rustfmt is run) during the bootstrap bump, as rustfmt converts `~const` into `[const]`. After this we can remove the `~const` support from the parser Caveat discovered during impl: there is no legacy bare trait object recovery for `[const] Trait` as that snippet in type position goes down the slice /array parsing code and will error r? ``@fee1-dead`` cc ``@nikomatsakis`` ``@traviscross`` ``@compiler-errors``
Remove let_chains unstable feature Per rust-lang/rust#53667 (comment) (but then I also noticed rust-lang/rust#140722) This replaces the feature gate with a parser error that says let chains require 2024. A lot of tests were using the unstable feature. I either added edition:2024 to the test or split out the parts that require 2024.
|
Ah, non-trivial merge conflicts. |
|
Oh, I literally did the exact same thing just now! #6682 👀 |
jieyouxu
changed the title
| clap-cargo = "0.12.0" | ||
| diff = "0.1" | ||
| dirs = "5.0" | ||
| dirs = "6.0" |
There was a problem hiding this comment.
Remark: re. Cargo.lock changes... Ah this is why, we bumped dirs on the r-l/r side...
Yes, and will reconverge when you sync back up. Typically you do not want there to be a lot of time to have passed between a sync and merging new PRs to avoid this problem. Clippy does a sync every 2-3 weeks which seems to work okay. |
There was a problem hiding this comment.
I don't have merge access but this looks about right.
@calebcartwright @ytmimi I'm happy to serve the role of doing cursory reviews for smaller changes (where there's less likely to be any architectural questions) if you think that would help.
|
I am also happy to do some interim reviews to help with the capacity |
|
I don't have bandwidth for maintaining rustfmt in addition to what I'm already maintaining, but can help with smaller cursory reviews as well in the interim if that's needed. |
|
Kicked off the Diff-Check |
|
Looks like something impacted import ordering in rustc. |
|
I'll review the diff more carefully a little later to see if I can figure out what's going on similar to what I did in #6531 (comment) |
|
I didn't have as much time as I thought to dig into the formatting diff yesterday. I'd like to review the changes carefully before we merge any subtree-push so that we have a clear understand on where all the changes are coming from. I likely won't have much time to look into this until early next week. |
|
Yeah sounds good. No rush :) |
jieyouxu
added
the
A-subtree-syncs
|
W.r.t. Diff-Check: Did something get messed up with version="Two" and the style edition changes? All the diffs I am seeing look like stuff related to sorting and version="One" stuff like |
|
@fee1-dead It's possible that there's some sort of mismatch here. I know we need to update the We could try to update the Diff-Check job to take a |
|
(Let me know if you would like me to fix the merge conflict with a force-push, have not done so to avoid making it annoying to review.) |
jieyouxu
added
the
E-needs-investigation
Two PRs (for the existing Diff Check setup): |
20 participants
Bumping the toolchain version as part of a git subtree push.
current toolchain (nightly-2025-04-02):
latest toolchain (nightly-2025-10-07):
Review remarks
I tried my best to mimic prior rustfmt syncs (e.g. #6531), and tried to piece this together based on
clippy's subtree sync advice.For the merge commit itself, I had to fix two merge conflicts:
src/types.rs(related todyn*unstable feature removal cf. Remove support fordyn*from the compiler rust#143036), andsrc/closures.rs(trivial import conflict).As far as I can tell, rustfmt repo does not have any kind of auto toolchain bump tooling, so I created the last
rust-toolchainbump commit (08586bb) manually.I also had to:
cfg_match!changes that are present in this repo which are not present in the tree in r-l/r... So in some sense the two trees seem to have diverged a bit?=for the key-value separator instead of:) and a missing// rustfmt-edition: 2024test header.Cargo.lock(dirsupdate on the r-l/r side).