You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which parses fine but gives the following, relatively confusing error message:
loop.chpl:1: In module 'loop':
loop.chpl:1: error: 'chpl__tuple_blank' undeclared (first use this function)
This is because currently, we use the same production rules to match both the left and right hand sites of declarations (so, the e in for e in is parsed the same way as var 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:
Allow _ to make it from the parser to the AST, even in non-declaration contexts like var x = _.
Add a post-parse check to detect _ and warn about it, except in declaration sites
Make that post-parse check have a nicer error message :)
The text was updated successfully, but these errors were encountered:
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
Closes#25002. Closes#25001.
This PR takes exactly the steps I outlined in #25002. Specifically, it:
1. Allows `_` to make it from the parser to the AST, even in
non-declaration contexts like `var x = _`.
2. Adds a post-parse check to detect `_` and warn about it, _except_ in
places where it's allowed
3. Makes that post-parse check have a nicer error message :)
While there, it improves the error message for `for` in particular,
where it explains what the user should do if they don't care about their
identifier. Thus, one gets:
<img width="1121" alt="Screen Shot 2024-06-04 at 4 23 53 PM"
src="https://github.com/chapel-lang/chapel/assets/4361282/73791220-82f3-4928-b2ef-1eaf4f3d68f5">
That last line is specific to indexable loops.
Reviewed by @vasslitvinov -- thanks!
# Testing
- [x] paratest
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
e
infor e in
is 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: