-
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
Fix regression 61475 #61500
Fix regression 61475 #61500
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
r? @petrochenkov perhaps? |
If we also wanted a test here, this seemed small and enough to reproduce on beta/nightly (but accepted on stable): enum E {
A, B
}
fn main() {
match &&E::A {
&&E::A => {
}
&&E::B => {
}
};
} |
@bors r+ rollup |
📌 Commit 5716e26 has been approved by |
Fix regression 61475 Addresses rust-lang#61475.
Fix regression 61475 Addresses rust-lang#61475.
Rollup of 5 pull requests Successful merges: - #61069 (Make MIR drop terminators borrow the dropped location) - #61453 (Remove unneeded feature attr from atomic integers doctests) - #61488 (Fix NLL typeck ICEs) - #61500 (Fix regression 61475) - #61523 (Hide gen_future API from documentation) Failed merges: r? @ghost
discussed at T-compiler meeting; approved for beta-backport |
[beta] Rollup backports Rolled up: * [beta] Permit unwinding through FFI by default #61569 Cherry-picked: * upgrade rustdoc's `pulldown-cmark` to 0.5.2 #60802 * Fix overflowing literal lint in loops #61098 * Revert edition-guide toolstate override #61110 * Turn turbo 🐟 🍨 into an error #61189 * Bump hashbrown to 0.4.0 #61388 * Fix regression 61475 #61500 r? @ghost
[beta] Rollup backports Rolled up: * [beta] Permit unwinding through FFI by default #61569 Cherry-picked: * upgrade rustdoc's `pulldown-cmark` to 0.5.2 #60802 * Fix overflowing literal lint in loops #61098 * Revert edition-guide toolstate override #61110 * Turn turbo 🐟 🍨 into an error #61189 * Bump hashbrown to 0.4.0 #61388 * Fix regression 61475 #61500 r? @ghost
// If the next token is a keyword, then the tokens above *are* unambiguously incorrect: | ||
// `if x { a } else { b } && if y { c } else { d }` | ||
if !self.look_ahead(1, |t| t.is_reserved_ident()) => { |
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.
Was the intention here to catch if
, match
, loop
, while
and for
? Because it also triggers for {} &&false
(which would otherwise parse the same way as {} & &false
), despite {} &&0
being unaffected.
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.
Oh, this seems coincidental to #74233, and not actually a bug in itself.
@@ -2847,7 +2847,11 @@ impl<'a> Parser<'a> { | |||
// want to keep their span info to improve diagnostics in these cases in a later stage. | |||
(true, Some(AssocOp::Multiply)) | // `{ 42 } *foo = bar;` or `{ 42 } * 3` | |||
(true, Some(AssocOp::Subtract)) | // `{ 42 } -5` | |||
(true, Some(AssocOp::Add)) => { // `{ 42 } + 42 | |||
(true, Some(AssocOp::LAnd)) | // `{ 42 } &&x` (#61475) | |||
(true, Some(AssocOp::Add)) // `{ 42 } + 42 |
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.
The Add
case (although not introduced in this PR) is also a bit strange... surely Rust expressions can't start with +
?
That is, Rust has no "unary plus" operator, like other languages do.
(true, Some(AssocOp::Multiply)) | // `{ 42 } *foo = bar;` or `{ 42 } * 3` | ||
(true, Some(AssocOp::Subtract)) | // `{ 42 } -5` |
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.
If these are included, why isn't { 42 } & 3
? Surely the have the same property?
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.
Ah this seems like a reporting-only heuristic and only the can_continue_expr_unambiguously
check is relevant to what I was seeing.
Looking again at this, I don't think this PR was necessary, it seems to have worked around the bug without fully fixing it. |
Addresses #61475.