[syntax-errors] detect single starred expression assignment x = *y

[abhijeetbodas2001]

Summary

Part of #17412

Starred expressions cannot be used as values in assignment expressions.
Add a new semantic syntax error to catch such instances.
Note that we already have ParseErrorType::InvalidStarredExpressionUsage to catch some starred expression errors during parsing, but that does not cover top level assignment expressions.

Test Plan

• Added new inline tests for the new rule
• Found some examples marked as "valid" in existing tests (_ = *data), which are not really valid (per this new rule) and updated them
• There was an existing inline test - assign_stmt_invalid_value_expr which had instances of * expression which would be deemed invalid by this new rule. Converted these to tuples, so that they do not trigger this new rule.

[abhijeetbodas2001]

@ntBre could you review?

[github-actions]

ruff-ecosystem results

Linter (stable)

ℹ️ ecosystem check encountered linter errors. (no lint changes; 1 project error)

bokeh/bokeh (error)

ruff check --no-cache --exit-zero --ignore RUF9 --no-fix --output-format concise --no-preview --select ALL

Failed to clone bokeh/bokeh: error: 3300 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[dhruvmanila]

Let's use the same convention for the message as other similar syntax errors: "Starred expression cannot be used here" (cc @ntBre)

[ntBre]

Oh, that is actually what we used for the existing InvalidStarExpression variant, so that's my bad. I think the closest to the other variants would be something like "cannot use a starred expression here," but the current value is identical to CPython.

[dhruvmanila]

I don't think we necessarily need to have the same message as CPython.

I think the closest to the other variants would be something like "cannot use a starred expression here,"

Oh interesting. IIRC, the parser has messages like "Yield expressions cannot be used here", etc. which is where my recommendation comes from.

[abhijeetbodas2001]

IIRC, the parser has messages like "Yield expressions cannot be used here"

There's also the exact message you mentioned above for star expressions:

ruff/crates/ruff_python_parser/src/error.rs

Lines 229 to 231 in bc0a5aa

	ParseErrorType::InvalidStarredExpressionUsage => {
	f.write_str("Starred expression cannot be used here")
	}

Should I change the syntax error to this message then?

[abhijeetbodas2001]

Hi, bumping this once again.
It is not clear to me whether the message needs to be changed or not.
(Although changing makes sense to me, happy to do that).

[dhruvmanila]

I'd recommend changing the message to "Starred expression cannot be used here" to be consistent with what the parser emits and other similar messages emitted by the Ruff parser. It'd be useful if that change could be done in a separate PR but if that's too much to ask, it's fine to include it in this PR itself.

[abhijeetbodas2001]

Opened #17772 for the message change.

[ntBre]

Thanks, this is looking good. I think we can revert at least one of the snapshot updates and add a couple more interesting test_ok cases, but otherwise this looks good.

Let's follow up with a small PR updating the error message for this variant, as Dhruv suggested. I think it's okay to land this first since it's just reusing the current message.

[ntBre]

I think we can just leave this file alone. It doesn't look like the snapshots changed at all, so I don't think it's worth renaming the file or updating the tests, unless I'm missing something. They don't even trigger the new semantic error, right?

[abhijeetbodas2001]

They do trigger the new rule.

        257 │+1 | x = *a and b
        258 │+  |     ^^^^^^^^ Syntax Error: can't use starred expression here
        259 │+2 | x = *yield x
        260 │+3 | x = *yield from x
        261 │+  |
        262 │+
        263 │+
        264 │+  |
        265 │+1 | x = *a and b
        266 │+2 | x = *yield x
        267 │+  |     ^^^^^^^^ Syntax Error: can't use starred expression here
        268 │+3 | x = *yield from x
        269 │+4 | x = *lambda x: x

I had removed the assignments so that they do not trigger it.

[dhruvmanila]

I think that would be changing what the test was suppose to do. It's suppose to test that a starred expression involved in an assignment uses the correct precedence which is bitwise_or as per the grammar. We should retain this test but update it such that it still maintains what the original intent was. Now that the star expressions are not allowed at the top level, we can update the code to include the star expressions inside a list / tuple. For example:

x = (*a and b,)

[ntBre]

Ah, my mistake for not seeing that these would be affected. Thanks Dhruv for clarifying the intent of the tests, that looks like a great suggestion.

[abhijeetbodas2001]

Thanks for the explanation! Makes sense. For the non-yield test cases, I followed the pattern you mentioned, putting the expression inside a list.
For the yield test cases, I had to create a two-element tuple, because:

• Changing to (*yield x,) is not good enough, since this is still a "Starred expression" as a whole as per the AST
• Changing to ((*yield x),) triggers another of the "Starred expression cannot be used here" errors, namely this one:
  

  ruff/crates/ruff_python_parser/tests/snapshots/invalid_syntax@expressions__parenthesized__parenthesized.py.snap

  Lines 62 to 64 in f11d9cb

  	1 | # Starred expression isn't allowed in a parenthesized expression.
  	2 | (*x)
  	| ^^ Syntax Error: Starred expression cannot be used here

To avoid this being triggered, I went with a two-element tuple -- (42, *yield from x)

[dhruvmanila]

Thanks for following up, that works.

[abhijeetbodas2001]

Addressed two of the review comments, but Brent, please see the unresolved thread at #17624 (comment).

As you suggested, I'll make a follow up PR to edit the messages once this one is in.

[abhijeetbodas2001]

Thanks a lot for the reviews! I have addressed all the comments and pushed.

[dhruvmanila]

Looks good, I've mainly looked at the test cases. I'll leave the final review to @ntBre

[ntBre]

Looks great, thank you!