mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering - #160551
Merged
Conversation
Collaborator
|
Some changes occurred in match lowering cc @Nadrieril |
rustbot
added
S-waiting-on-review
Collaborator
|
|
This comment has been minimized.
This comment has been minimized.
Collaborator
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
Member
Author
|
This PR isn't motivated by perf, but I'm curious to see if it has any measurable perf effect. @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 6, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering
Contributor
This comment has been minimized.
This comment has been minimized.
Collaborator
|
Finished benchmarking commit (fcfa9a7): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up. @rustbot label: -S-waiting-on-perf -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.5%, secondary -2.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis perf run didn't have relevant results for this metric. Binary sizeResults (primary -0.0%, secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 460.81s -> 462.278s (0.32%) |
rustbot
removed
the
S-waiting-on-perf
Member
Author
|
A tiny regression in match-stress is potentially real, but not worth worrying about. |
Member
|
This is great, code feels a lot more robust like this! @bors r+ |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 31, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 31, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 31, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Aug 31, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 31, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 31, 2026
…uwer Rollup of 12 pull requests Successful merges: - #162045 (`rust-analyzer` subtree update) - #162077 (compiler-builtins subtree update) - #137720 (support `#[target_feature(enable = ...)]` on `#[naked]` functions) - #160534 (stabilize smart pointer map functions) - #160551 (mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering) - #161929 (explicitly track inherent const generic args kind) - #162063 (Switch dist-aarch64-linux to EC2 and update dist-x86_64-linux) - #161937 (A series of Polonius Alpha refactors) - #162014 (Move more `rustdoc-html` tests using `--test` into the right folder) - #162051 (`rustc_feature` cleanups) - #162055 (remove `_{style}` recovery for diagnostic structs) - #162075 (Move track_caller on closures gating to attribute parsing)
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Sep 1, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Sep 1, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 1, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 1, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 1, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 1, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 1, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 1, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 1, 2026
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 1, 2026
…uwer Rollup of 16 pull requests Successful merges: - #137720 (support `#[target_feature(enable = ...)]` on `#[naked]` functions) - #160534 (stabilize smart pointer map functions) - #160551 (mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering) - #160989 (Make sin, cos, exp, exp2, log, log2, log10 generic) - #161861 (mir_build: Clarify parts of if-condition lowering) - #161929 (explicitly track inherent const generic args kind) - #162040 (bootstrap: stage0 to cbae9b4) - #162063 (Switch dist-aarch64-linux to EC2 and update dist-x86_64-linux) - #161353 (Add test for parallel compiler reproducible build) - #161937 (A series of Polonius Alpha refactors) - #162051 (`rustc_feature` cleanups) - #162055 (remove `_{style}` recovery for diagnostic structs) - #162075 (Move track_caller on closures gating to attribute parsing) - #162079 (std: implement `File::fsync` for Hermit) - #162097 (Deduplicate `InstrumentFnAttr`) - #162115 (fix typo in feature documentation)
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 1, 2026
Rollup merge of #160551 - Zalathar:inter-pat, r=Nadrieril mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of #155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to #158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
Collaborator
|
Finished benchmarking commit (1e61481): comparison URL. Overall result: ❌✅ regressions and improvements - no action neededBenchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up. @rustbot label: -S-waiting-on-perf -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary -2.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis perf run didn't have relevant results for this metric. Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: missing data |
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
5 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.
This PR has two related parts.
The first commit divides the various fields of InterPat into three different
InterPatKindvariants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of mir_build: Add an extra intermediate step in MIR building for patterns #155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split.As a follow-on, the second commit then splits MatchPairTree into two different
MatchPairKindvariants: one for or-pattern nodes, and one for “testable” nodes.In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent.
There should be no change to compiler output.
MatchPairTreeinto testable and or-pattern variants #158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind.r? Nadrieril