[parser] Fix false syntax error for match-like annotated assignments#23297
[parser] Fix false syntax error for match-like annotated assignments#23297dhruvmanila merged 2 commits intoastral-sh:mainfrom
Conversation
ntBre
left a comment
There was a problem hiding this comment.
Can you add a regression test for this showing that the issue is now resolved?
|
50e4862 to
1890778
Compare
|
This sounds like a reasonable approach to me but I'm wondering if @dylwil3 had any examples in mind w.r.t. this comment. Do you think if this will create any issue in the error recovery? I can't think of any example. |
You're right, I think once we have the newline there's no valid syntax, non-match statement that could fit there so this is probably fine. (Maybe CPython is doing more work than necessary in that code snippet I linked) |
Yeah, I don't think so either. Another thing to note is that this code path is only taken once the parser has ruled out all the obvious cases where it can easily classify We were doing something similar to CPython before where we would perform infinite lookahead :) |
Summary
Fixes #22528.
The parser incorrectly treats
match[0]: intandmatch [x, y, z]: {dict}as the start of amatchstatement, producing a false syntax error. The issue is that the parser checks only for a colon after the subject expression to confirm a match statement, but annotated assignments withmatchas a variable name also have a colon.This PR adds a
self.peek() == TokenKind::Newlineguard to the colon check, so thatmatchis only treated as a keyword when the colon is followed by a newline (which is required for a match statement's body). When the colon is followed by something else (like a type annotation value), it falls through to the soft-keyword-as-identifier path.Test Plan
All 42 existing match-related parser tests pass. No snapshot changes needed. Clippy clean.
Reproduction from the issue: