Disallow tuple expressions with underscores in non-declaration contexts #25002
Assignees
Labels
Comments
1 task
DanilaFe
added a commit
that referenced
this issue
May 7, 2024
Fixes #25000 (what a fun issue number!). This PR disallows writing `(_)`, to match the already-disallowed `_`. Prior to this PR, the following program did not parse: ```Chapel var x = _; ``` But the following alternate version did: ```Chapel var x = (_); ``` This was because the parenthesized-expression grammar rule used `tuple_component`, which allows `_` (`(_, )` can be used to unpack 1-tuples in loops). As a result, this fixes the odd issue in which writing a loop over `(_)` resulted in an internal error, while `_` resulted in a normal syntax error. This raised some follow-up concerns: 1. should we have a nicer error message when a user writes `_` where it doesn't belong? #25001 2. should we really allow `_` in all tuple expressions? currently we do. #25002 In the meantime, this PR turns the error in #25000 from an internal error into a syntax error. Reviewed by @vasslitvinov -- thanks! ## Testing - [x] paratest
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Today, you can write the following:
Which parses fine but gives the following, relatively confusing error message:
This is because currently, we use the same production rules to match both the left and right hand sites of declarations (so, the
einfor e inis parsed the same way asvar x = e). Since we need tuple expressions on the left -- to allow value-ignoring assignments -- we need the_. To improve the situation w.r.t. #25001, I think the play is to do the following:_to make it from the parser to the AST, even in non-declaration contexts likevar x = _._and warn about it, except in declaration sitesThe text was updated successfully, but these errors were encountered: