Skip to content

gh-153171: Produce specialized syntax errors in more cases#153193

Closed
serhiy-storchaka wants to merge 1 commit into
python:mainfrom
serhiy-storchaka:error-rule-coverage
Closed

gh-153171: Produce specialized syntax errors in more cases#153193
serhiy-storchaka wants to merge 1 commit into
python:mainfrom
serhiy-storchaka:error-rule-coverage

Conversation

@serhiy-storchaka

Copy link
Copy Markdown
Member

Continuation of gh-153171: a coverage audit of the error rules found more cases where a specialized error message is not produced in all positions where the invalid construct can occur.

  • 'not' after an operator must be parenthesized was only reported after arithmetic and unary operators. Now it is also reported after shift, bitwise, comparison and power operators (1 << not x, 1 & not x, 1 < not x, 2 ** not x). Each operator tier gets its own error rule requiring the actual preceding operator -- a single rule matching bare not at the operand position would misfire when a valid leading not expression is followed by garbage (the "no misleading errors" cases in test_syntax guard exactly this).
  • expected default value expression was not reported for a missing parameter default before : in lambda expressions (lambda x=: 0 reported generic "invalid syntax").
  • A missing type parameter default value (def f[T=](): pass, type X[T=] = int) reported a misleading expected '('. It could not be handled in invalid_type_param because the base rule succeeds without consuming = (the default is optional), so it is handled at the type parameter list level.

The remaining known gap (no specialized error for a starred expression at an operand position, e.g. x = 1 + *y) is left out: an error alternative at the operand rule preempts better specialized errors in the second pass (e.g. X[**A: str] is explored as a subscript with a slice, and del (*x,) loses "cannot delete starred"), so it needs a different approach.

🤖 Generated with Claude Code

Report "'not' after an operator must be parenthesized" also for
'not' after shift, bitwise, comparison and power operators (each
operator tier gets its own error rule; a single rule matching bare
'not' at the operand position would misfire when a valid leading
'not' expression is followed by garbage).

Report "expected default value expression" also for a missing
parameter default value before ':' in lambda expressions and for
a missing type parameter default value (previously the latter
reported a misleading "expected '('").

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant