subtree-push nightly-2025-10-07 #6681
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
"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 <[email protected]>
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.
Remove two duplicated crates These commits remove `toml-0.5.11` and `dirs-sys-0.4.1`. There are later versions of those same crates already in the tree. Found with `cargo tree -d`. r? ``@jieyouxu``
test(rustfmt): Verify frontmatter is preserved This is to prove that the frontmatter is preserved. The choices in tests is intended for showing the different parts of the proposed Style Guide for frontmatters (rust-lang/rust#145617). While rustfmt is developed in a different repo, work involving upstream integration is blocked on some work that is being finished up in that repo. I was told that it would be ok to post against this repo in the mean time. Tracking issue: rust-lang/rust#136889
Normally, changes to rustfmt go into the separate repo. But, in this case, the bug is introduced in a local change and therefore isn't present in the rustfmt repo.
add span to struct pattern rest (..) Struct pattern rest (`..`) did not retain span information compared to normal fields. This patch adds span information for it. The motivation of this patch comes from when I implemented this PR for Clippy: rust-lang/rust-clippy#15000 (comment) It is possible to get the span of the Et cetera in a bit roundabout way, but I thought this would be nicer.
fix a constness ordering bug in rustfmt Normally, changes to rustfmt go into the separate repo. But, in this case, the bug is introduced in a local change and therefore isn't present in the rustfmt repo. Related to: rust-lang/rust#146071 Fixes rust-lang#6619.
I.e. do not mark them as used, or non-speculative loaded, or similar. Previously they were sometimes finalized during early resolution, causing issues like rust-lang/rust#144793 (comment).
Bumping the toolchain version as part of a git subtree push. current toolchain (nightly-2025-04-02): - 1.88.0-nightly (e2014e876 2025-04-01) latest toolchain (nightly-2025-10-07): - 1.92.0-nightly (f6aa851db 2025-10-07)
This comment was marked as resolved.
This comment was marked as resolved.
|
Ah, non-trivial merge conflicts. |
|
Oh, I literally did the exact same thing just now! #6682 👀 |
jieyouxu
changed the title
jieyouxu
commented
Oct 8, 2025
jieyouxu
commented
Oct 8, 2025
| 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...
Merged
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. |
Manishearth
approved these changes
Oct 8, 2025
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.
fee1-dead
approved these changes
Oct 8, 2025
|
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. |
shulaoda
approved these changes
Oct 8, 2025
|
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) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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).