[DO NOT MERGE] subtree-push nightly-2025-12-06 #6743
Draft
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 <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.
By updating rustfmt to use `dirs-6.0.0`.
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).
…,traviscross Implement pin-project in pattern matching for `&pin mut|const T` This PR implements part of rust-lang/rust#130494. It supports pin-project in pattern matching for `&pin mut|const T`. ~Pin-projection by field access (i.e. `&pin mut|const place.field`) is not fully supported yet since pinned-borrow is not ready (rust-lang/rust#135731).~ CC ``````@traviscross``````
mgca: Add ConstArg representation for const items tracking issue: rust-lang/rust#132980 fixes rust-lang/rust#131046 fixes rust-lang/rust#134641 As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item. To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR. We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
…y-2025-12-06 Note that this merge conflict only makes `rustfmt` **buildable**, some tests (such as idempotency!) are still failing! # Merge conflict resolution - Manually retained `src/parse/macros/asm.rs` (upstream change is rust-lang/rust#140367, local removal was rust-lang#6698). - Several divergences between the `Option<String>` `rust-lang/rust` copy is stuck on, versus the `RewriteResult`s in `rustfmt` tree. When this happens, I changed the signature to use `RewriteResult` to match `rustfmt` tree. - Changed some helpers e.g. `offset_left` to `offset_left_opt`, while for others I had to add spans in places. Whenever this is needed, I take the `rustfmt` version as the "ground truth" and tried to keep close to `rustfmt`s version as much as possible. - There's a few place that I had to add `.unknown_error()` to to convert between missing snippets' `Option<usize>` to `RewriteResult` to match `rustfmt` tree's version. - Removed a few `.()`s to match `rustfmt` tree's version. - Changed a few `.rewrite()` to `.rewrite_result()`. - Changed a few `return None;` -> `Err(RewriteError::Unknown);`. - `format_trait_alias` is a bit non-trivial, the signature diverges. I modified the signature and body to match the `rustfmt` tree's version, because the rust copy's signature obviously does not have sufficient span info for rustfmt to work with. However, I also had to kinda mix-and-match, because the `rustfmt` tree's version did not have const formatting. - I had to improvise here and added a `constness: &ast::Const` parameter. - Please review carefully, this diverges from *both* copies! - Fixed a trivial conflict from removal of AST `P<>` (`item.into_inner()` -> `*item`). - Fixed removal of `TokenKind::{OpenDelim,CloseDelim}` with `TokenKind:: {OpenBrace,CloseBrace}` directly. - Changed `FmtVisitor::with_context` to the `rustfmt` version where `RewriteResult` is expected of the closure return. Also modified some `rw` -> `rw.ok()` to match `rustfmt`.
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-12-06): - 1.94.0-nightly (ba86c0460 2025-12-06)
jieyouxu
added
the
A-subtree-syncs
…=2027" This effectively reverts commit a7e0c15. This change made it into the 2024 style edition so we can't defer it to 2027.
We didn't get this change synced with r-l/rust before the release of the 2024 edition, so trying to do a subtree-sync with this mod sorting logic for `style-edition=2024` would be a breaking change.
1. The test annotations have the wrong syntax. 2. The test is missing a Rust language Edition (>= 2024) for if-let chains. Detected in a subtree sync attempt.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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-12-06):
Test failure debugging log
Idempotence tests are failing:
Cherry-picked in:
... now one test is causing idempotency to fail.
It's broken test annotations in a test, fix is #6744.
Cherry-picked in:
tests/source/issue-6202/long_pat.rs#6744