-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
or-patterns: Push PatKind/PatternKind::Or
at top level to HIR & HAIR
#64508
Merged
Merged
Changes from 19 commits
Commits
Show all changes
22 commits
Select commit
Hold shift + click to select a range
146cb8e
or-patterns: remove hack from lowering.
Centril b2f903c
or-patterns: `hir::Arm::pats` -> `::pat` + `Arm::top_pats_hack`.
Centril 6579d13
or-patterns: normalize HIR pretty priting.
Centril 75fb42a
or-patterns: use `top_pats_hack` to make things compile.
Centril 89bbef3
check_match: misc cleanup.
Centril 4c34693
or-patterns: fix problems in typeck.
Centril 9d1c3c9
simplify `hir::Pat::walk_`.
Centril cc5fe6d
or-patterns: liveness/`visit_arm`: remove `top_pats_hack`.
Centril 9ca42a5
or-patterns: liveness: generalize + remove `top_pats_hack`.
Centril 57eeb61
or-patterns: remove `Arm::contains_explicit_ref_binding`.
Centril fb2cfec
or-patterns: euv/`arm_move_mode`: remove `top_pats_hack`.
Centril d7139f3
or-patterns: euv/`walk_arm`: remove `top_pats_hack`.
Centril 07deb93
or-patterns: middle/dead: make a hack less hacky.
Centril 0dfd706
or-patterns: rvalue_promotion: remove `top_pats_hack`.
Centril 38a5ae9
or-patterns: regionck/visit_arm: remove `top_pats_hack`.
Centril 9b406f1
or-patterns: regionck/`link_match`: remove `top_pats_hack`.
Centril 6bd8c6d
or-patterns: check_match: remove `top_pats_hack` for `check_for_bindi…
Centril 549756b
or-patterns: check_match: nix `top_pats_hack` passed to `check_patter…
Centril 56b055a
or-patterns: HAIR: `Arm.patterns: Vec<Pattern<'_>>` -> `.pattern: Pat…
Centril 05cc3c0
or-patterns: liveness: `is_argument` -> `is_param`.
Centril 370fbcc
or-patterns: #47390: we rely on names to exercise `IndexMap`.
Centril 0918dc4
or-patterns: middle/dead: remove `top_pats_hack`.
Centril File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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 file contains 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 file contains 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 file contains 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 file contains 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 file contains 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 file contains 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 file contains 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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is calling
each_binding_or_first
recursively going to have the right behaviour for nestedOr
patterns? Shouldn't it pick the first pattern only at the top level? (In which case, you can useeach_binding
instead and just check the top level at the call site.)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Using
c
for callback asf
is used forFieldPat
; could switch tog
for the callback instead.)(We discussed this a bit privately on Discord; The existing commentary in
define_bindings_in_pat
states that we only consider the first pattern since any later patterns must have the same bindings (and the first pattern is considered to have the authoritative set of ids). This suggests that we should do the same in nested positions as there should be no intrinsic semantic difference betweenSome(a @ 1) | Some(a @ 2)
andSome(a @ (1 | 2))
. That said, I don't really know why we only consider the first pattern and if we just use.each_binding(...)
uniformly for top/nested then the UI tests pass at least.)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at blame, it seems the comment was left by @eddyb 5 years ago in b062128. Maybe they still know. =P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's actually due to @nikomatsakis here: e47d2f6#diff-97c8d3b79a36724da452cf176a6a42b5R661-R663.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't even understand what the question is here. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nikomatsakis So your comment to a call of
.define_bindings_in_pat(...)
inliveness.rs
regardingExprKind::Match(...) =>
states that:Now, I don't exactly understand why this is, but my intuition says that if we want to extend this logic to nested or-patterns, e.g.
Some(A(x) | B(x))
then we should do the same think there. That is, in anyPatKind::Or(pats)
we will just visitpats[0]
and notpats[1..]
. That's what the code in this PR does now.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, so here's the problem. Presently we use the id of the AST node for a pattern binding as the variable's id -- but when you have e.g.
Foo(x) | Bar(x)
, you wind up with two id's forx
! Clearly all the alternatives must have the same set of bindings (i.e., they must all definex
), so yeah I dimly recall deciding that we would just use the id's from the first set of patterns to define the variables, and then check the remaining patterns against that first set.I think another viable approach would be to use some kind of fresh identifiers for the variables (not the id from the pattern node) and then be able to "resolve" each pattern node to that. Or perhaps to have a table of "redirects" where for most bindings the redirect is the identity, but for
|
patterns they point to the bindings from the first set.In any case I think you are correct that if we are moving
|
patterns further down, and we want to try and use the same strategy, then we only want to take the left-most branches (but check the other branches for consistency).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the elaboration!
Yea, that's what we do; I recently tweaked this logic in resolve here:
rust/src/librustc_resolve/late.rs
Lines 1121 to 1475 in 9b9d2af
Sounds interesting (but should be done in a follow-up if so). cc @petrochenkov may be interested.