[style] rustfmt `match`es with comments in or-patterns by estebank · Pull Request #156518 · rust-lang/rust

estebank · 2026-05-13T02:35:58Z

Using rust-lang/rustfmt#6893, I reformatted the whole codebase. The result is that matches 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 `name`` in comments.

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.

rustbot · 2026-05-13T02:36:01Z

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

rustbot · 2026-05-13T02:36:04Z

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler, types
compiler, types expanded to 73 candidates
Random selection from 17 candidates

Thanks VSCode!

rustbot · 2026-05-13T02:41:07Z

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

The Clippy subtree was changed

cc @rust-lang/clippy

The Miri subtree was changed

cc @rust-lang/miri

The run-make-support library was changed

cc @jieyouxu

mejrs

r? me

View changes since this review

mejrs · 2026-05-15T18:09:13Z

                // assigning to P[i] requires P to be valid.
                ProjectionElem::Downcast(_/*adt_def*/, _/*variant_idx*/) =>
-                // assigning to (P->variant) is okay if assigning to `P` is okay
-                //
-                // FIXME: is this true even if P is an adt with a dtor?
-                { }
+                    // assigning to (P->variant) is okay if assigning to `P` is okay
+                    //
+                    // FIXME: is this true even if P is an adt with a dtor?
+                    {}


Are all these and the P[i] comments in the right place? Looks like they're below the arms they're talking about.

I moved them around to where I think they belong (both comments were shifted one down).

mejrs · 2026-05-15T18:13:05Z

                    | ty::PredicateKind::ConstEquate { .. }
-                    // Ambiguous predicates should never error
                    | ty::PredicateKind::Ambiguous
-                    // We never return Err when proving UnstableFeature goal.


Why did all these comments move up? 🤔 I don't think that's a good thing.

I moved them manually so that their formatting will continue being checked until rustfmt is fixed. Tried to keep that to a minimum.

Note that this is one of the most impacted files, as it has quite a big match expression, which means that the likelihood of formatting regressing in this match are high.

mejrs · 2026-05-15T18:15:11Z

+
            mir::Rvalue::BinaryOp(op, (ref lhs, ref rhs)) => {


Are the extra blank lines manual or did rustfmt do this? Here and elsewhere.

I believe these were manual. I did that once to keep consistency throughout a single match expression.

mejrs

@bors r+

View changes since this review

rust-bors · 2026-05-16T10:02:18Z

📌 Commit 5cd51c0 has been approved by mejrs

It is now in the queue for this repository.

[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 · 2026-05-16T10:10:52Z

💔 Test for d09436f failed: CI. Failed job:

auto - dist-various-2 (web logs, enhanced plaintext logs)

rust-log-analyzer · 2026-05-16T10:13:36Z

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

#13 DONE 23.3s

#14 [ 6/25] RUN apt-key adv --batch --yes --keyserver keyserver.ubuntu.com --recv-keys 74DA7924C5513486
#14 0.164 Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
#14 0.182 Executing: /tmp/apt-key-gpghome.eJ8S2cwtYf/gpg.1.sh --batch --yes --keyserver keyserver.ubuntu.com --recv-keys 74DA7924C5513486
#14 0.815 gpg: key 74DA7924C5513486: public key "Igor Kozhukhov <igor@dilos.org>" imported
#14 0.819 gpg: Total number processed: 1
#14 0.819 gpg:               imported: 1
#14 DONE 0.9s

Kobzol · 2026-05-16T18:55:39Z

@bors retry

Spurious failure fixed by #156640.

[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.

Rollup of 6 pull requests Successful merges: - #152852 (Remove driver_lint_caps) - #156121 (compiler: suggest `.collect()` when `String` is expected and `Iterator` is found) - #156518 ([style] rustfmt `match`es with comments in or-patterns) - #156596 (Split `LintExpectationId`s) - #156577 (Test EII UI tests with prefer-dynamic) - #156633 (Add regression test for issue #41261)

rust-bors · 2026-05-17T04:44:50Z

☀️ Test successful - CI
Approved by: mejrs
Duration: 3h 17m 3s
Pushing 281c97c to main...

github-actions · 2026-05-17T04:48:11Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing d3cd040 (parent) -> 281c97c (this PR)

Test differences

Show 110 test diffs

110 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 281c97c3240a9abd984ca0c6a2cd7389115e80d5 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

dist-ohos-x86_64: 1h 3m -> 1h 20m (+27.5%)
dist-ohos-aarch64: 1h 3m -> 1h 20m (+27.4%)
dist-armhf-linux: 1h 11m -> 1h 31m (+27.1%)
dist-riscv64-linux: 1h 12m -> 1h 29m (+23.5%)
dist-i686-mingw: 2h 48m -> 2h 11m (-22.1%)
dist-i686-msvc: 2h 26m -> 1h 54m (-22.1%)
dist-x86_64-mingw: 2h 40m -> 2h 6m (-21.1%)
dist-various-2: 35m 54s -> 42m 40s (+18.8%)
optional-x86_64-gnu-parallel-frontend: 2h 22m -> 2h 48m (+18.8%)
dist-arm-linux-gnueabi: 1h 30m -> 1h 13m (-18.5%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 13, 2026

rustbot assigned wesleywiser May 13, 2026

Remove a bunch of stray backticks

701e494

Thanks VSCode!

mejrs reviewed May 15, 2026

View reviewed changes

rustbot assigned mejrs and unassigned wesleywiser May 15, 2026

Place comment in the right place

5cd51c0

mejrs approved these changes May 16, 2026

View reviewed changes

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 16, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 16, 2026

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 16, 2026

GuillaumeGomez mentioned this pull request May 16, 2026

Rollup of 6 pull requests #156652

Closed

This comment has been minimized.

Sign in to view

rust-bors Bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 17, 2026

rust-bors Bot merged commit 281c97c into rust-lang:main May 17, 2026
12 checks passed

rustbot added this to the 1.97.0 milestone May 17, 2026

This was referenced May 17, 2026

Implement borrowck for &pin mut|const $place #153693

Open

Fix unused_parens for pinned reference patterns #156089

Open

Uh oh!

Conversation

estebank commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented May 13, 2026

Uh oh!

rustbot commented May 13, 2026

Uh oh!

rustbot commented May 13, 2026

Uh oh!

mejrs left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mejrs May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

estebank May 16, 2026

Choose a reason for hiding this comment

Uh oh!

mejrs May 15, 2026

Choose a reason for hiding this comment

Uh oh!

estebank May 15, 2026

Choose a reason for hiding this comment

Uh oh!

estebank May 16, 2026

Choose a reason for hiding this comment

Uh oh!

mejrs May 15, 2026

Choose a reason for hiding this comment

Uh oh!

estebank May 15, 2026

Choose a reason for hiding this comment

Uh oh!

mejrs left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors Bot commented May 16, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 16, 2026

Uh oh!

rust-log-analyzer commented May 16, 2026

Uh oh!

Kobzol commented May 16, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 17, 2026

Uh oh!

Uh oh!

github-actions Bot commented May 17, 2026

Test differences

Job duration changes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

estebank commented May 13, 2026 •

edited

Loading

mejrs left a comment •

edited by rustbot

Loading

mejrs May 15, 2026 •

edited

Loading

mejrs left a comment •

edited by rustbot

Loading