mir_build: Don't use a mixture of THIR pattern kinds for pin-patterns #150121
+35
−40
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
This avoids having to awkwardly ignore the `Pinnedness` field.
Collaborator
|
Some changes occurred in match checking cc @Nadrieril Some changes occurred in match lowering cc @Nadrieril |
rustbot
added
S-waiting-on-review
Collaborator
|
|
Member
|
Oh, the use of @bors r+ rollup |
Collaborator
bors
added
S-waiting-on-bors
rust-timer
added a commit
that referenced
this pull request
Dec 19, 2025
Rollup merge of #150121 - Zalathar:pin-pat, r=Nadrieril mir_build: Don't use a mixture of THIR pattern kinds for pin-patterns While looking for improvements to match-lowering, I had been trying to figure out why pin-patterns sometimes use `PatKind::Deref` and sometimes use `PatKind::DerefPattern`, which seemed confusing to me. In particular, both pattern kinds are being used with an inner type of `&` or `&mut`, which is very surprising. The conclusion I came to was that `DerefPattern` (normally associated with calls to Deref/DerefMut) was only being used for *implicit* pin-patterns produced by match-ergonomics adjustment, whereas `Deref` was being used for explicit pin-patterns. The inconsistency seems like a mistake to me, so this PR removes all uses of `DerefPattern` for pin-patterns, and consistently uses `PatKind::Deref` for pin-patterns instead. I'm not entirely happy with that outcome, because I think pin-patterns should probably have their own `thir::PatKind` variant, but this change will at least make that easier to achieve in a later PR. r? Nadrieril
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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.
While looking for improvements to match-lowering, I had been trying to figure out why pin-patterns sometimes use
PatKind::Derefand sometimes usePatKind::DerefPattern, which seemed confusing to me. In particular, both pattern kinds are being used with an inner type of&or&mut, which is very surprising.The conclusion I came to was that
DerefPattern(normally associated with calls to Deref/DerefMut) was only being used for implicit pin-patterns produced by match-ergonomics adjustment, whereasDerefwas being used for explicit pin-patterns.The inconsistency seems like a mistake to me, so this PR removes all uses of
DerefPatternfor pin-patterns, and consistently usesPatKind::Dereffor pin-patterns instead. I'm not entirely happy with that outcome, because I think pin-patterns should probably have their ownthir::PatKindvariant, but this change will at least make that easier to achieve in a later PR.r? Nadrieril