-
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
syntax: Rewrite parsing of patterns #23930
Conversation
r? @nrc (rust_highfive has picked a reviewer for you, use r? to override) |
Nice! |
if self.token == token::BinOp(token::Or) && | ||
self.restrictions.contains(RESTRICTION_NO_BAR_OP) { | ||
return lhs; | ||
} |
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.
Could you explain the reasoning behind why it is safe to remove this check please?
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.
Flag RESTRICTION_NO_BAR_OP is checked here but it isn't set anywhere, so I removed the check and the flag itself. RESTRICTION_NO_BAR_OP was used before in parse_pat
, see my line comments there.
lgtm, I just want to be clear about removing that one check |
self.look_ahead(2, |t| { | ||
*t != token::Comma && *t != token::CloseDelim(token::Bracket) | ||
}) { | ||
let start = self.parse_expr_res(RESTRICTION_NO_BAR_OP); |
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.
Here parse_expr_res(RESTRICTION_NO_BAR_OP)
was mistakenly used to parse plain identifier.
Ok, sounds good, thanks for the explanation. @bors: r+ d9a0ca01f3938efbb34587e3f52214d8c0bc1624 |
⌛ Testing commit d9a0ca0 with merge eb9ca18... |
💔 Test failed - auto-linux-64-x-android-t |
Rebased and fixed. |
⌛ Testing commit 76567a6 with merge 0640106... |
⛄ The build was interrupted to prioritize another pull request. |
⌛ Testing commit 76567a6 with merge 80def6c... |
Fixes #22757 Fixes #22972 Fixes #23044 Fixes #23151 Fixes #23597 Fixes #23656 Fixes #23929 It also fixes some other corner cases in range patterns, like incorrect spans or not accepting global paths after `...`. It passes `make check` but needs some additional tests (then it will fix #22546 as well), I'll write them today or tomorrow.
Fixes rust-lang#22757 Fixes rust-lang#22972 Fixes rust-lang#23044 Fixes rust-lang#23151 Fixes rust-lang#23597 Fixes rust-lang#23656 Fixes rust-lang#23929 It also fixes some other corner cases in range patterns, like incorrect spans or not accepting global paths after `...`. It passes `make check` but needs some additional tests (then it will fix rust-lang#22546 as well), I'll write them today or tomorrow.
@petrochenkov Did you mean to say that you'd add the test cases in a separate PR? As it is, none of the fixed issues have any related tests so perhaps we should reopen them? |
@jakub- |
This was supposed to be a part of rust-lang#23930
cc @pnkfelix |
@bombless I reopened that issue for you. |
Awesome list of fixes. |
@bombless thanks for the pro-active note. However, during triage (I think), the team decided as noted in e.g. this comment that we would keep the syntax, and that we just needed to exercise the edge cases more thoroughly. |
But, skimming this PR, it seems like it did not actually add any tests relevant to #22546, so I guess that issue should remain open. |
Fixes #22757
Fixes #22972
Fixes #23044
Fixes #23151
Fixes #23597
Fixes #23656
Fixes #23929
It also fixes some other corner cases in range patterns, like incorrect spans or not accepting global paths after
...
.It passes
make check
but needs some additional tests (then it will fix #22546 as well), I'll write them today or tomorrow.