Format match exprs even when or-patterns have comments#6893
Open
estebank wants to merge 3 commits into
Open
Conversation
When encountering comments in between elements of an or-pattern in a `match` expression, format the matched value, the arm body and the patterns of all other arms. *Only* skip the pattern with embedded comments.
rustbot
added
the
S-waiting-on-review
estebank
commented
May 12, 2026
| () => {} | ||
| () // Comment | ||
| | () => { | ||
| println!("Foo"); |
Contributor
Author
There was a problem hiding this comment.
This highlights the outstanding problem with this approach: the pattern is kept with bad formatting, where this should instead have been indented to the proper level.
Contributor
|
Diff-Check failed ❌. We probably have to gate this change on |
ytmimi
added
the
F-impacts-stable-unformatted-code
Contributor
|
@rustbot author |
rustbot
added
S-waiting-on-author
Collaborator
|
Reminder, once the PR becomes ready for a review, use |
Contributor
Author
rustbot
added
S-waiting-on-review
estebank
added a commit
to estebank/rust
that referenced
this pull request
May 13, 2026
Using rust-lang/rustfmt#6893, reformat the codebase. The result is that matches that *would have* been formatted under normal circumstances get their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR. Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
rust-bors Bot
pushed a commit
to rust-lang/rust
that referenced
this pull request
May 16, 2026
[style] rustfmt `match`es with comments in or-patterns Using rust-lang/rustfmt#6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR. Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime. (Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
May 16, 2026
[style] rustfmt `match`es with comments in or-patterns Using rust-lang/rustfmt#6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR. Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime. (Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
rust-bors Bot
pushed a commit
to rust-lang/rust
that referenced
this pull request
May 17, 2026
[style] rustfmt `match`es with comments in or-patterns Using rust-lang/rustfmt#6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR. Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime. (Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
pull Bot
pushed a commit
to Kokoro2336/rust-analyzer
that referenced
this pull request
May 17, 2026
[style] rustfmt `match`es with comments in or-patterns Using rust-lang/rustfmt#6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR. Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime. (Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
pull Bot
pushed a commit
to xtqqczze/rust-lang-miri
that referenced
this pull request
May 17, 2026
[style] rustfmt `match`es with comments in or-patterns Using rust-lang/rustfmt#6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR. Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime. (Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
github-actions Bot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this pull request
May 18, 2026
[style] rustfmt `match`es with comments in or-patterns Using rust-lang/rustfmt#6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR. Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime. (Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
ytmimi
reviewed
May 22, 2026
Comment on lines
+24
to
+25
| /// rust edition 2027 | ||
| Edition2027, |
Contributor
There was a problem hiding this comment.
Wait, you mentioned in the FIXME below that rustc doesn't have an edition 2027 yet. In that case I'd prefer we don't add that here yet. It's fine that rustfmt has it's own style_edition to gate formatting changes outside of editions that are needed for parsing.
Please revert the Edition::Edition2027 changes from this PR. As long as things are gated on StyleEdition::Edition2027 then we should be good to move forward.
Contributor
Yeah, anything that count potentially introduce breaking formatting changes needs to be gated. From what I understand that's how the team has pretty much always operated. Things used to be gated on |
Contributor
|
@rustbot author |
rustbot
added
S-waiting-on-author
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
When encountering comments in between elements of an or-pattern in a
matchexpression, format the matched value, the arm body and the patterns of all other arms. Only skip the pattern with embedded comments.Fix #4119, fix #6491, cc #6044, cc #6663.
An alternative approach would be to make pre and post comments part of all patterns, which would allow us to keep them around and format or patterns properly, but wanted to have the minimal possible change that could address a common papercut I've noticed in
rustc.