Skip to content

go/parser: parser doesn't recognize valid type parameter list #52559

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
griesemer opened this issue Apr 26, 2022 · 3 comments
Closed

go/parser: parser doesn't recognize valid type parameter list #52559

griesemer opened this issue Apr 26, 2022 · 3 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.19

Comments

@griesemer
Copy link
Contributor

This is the go/parser version of issue #49482 so we can track the fixes separately as the go/parser changes are not a trivial port of the syntax parser changes.
@griesemer griesemer added the NeedsFix The path to resolution is known, but the work has not been done. label Apr 26, 2022
@griesemer griesemer added this to the Go1.19 milestone Apr 26, 2022
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/403696 mentions this issue: go/parser: parser to accept ~x as unary expression

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/403937 mentions this issue: go/parser: accept all valid type parameter lists

gopherbot pushed a commit that referenced this issue May 4, 2022
@griesemer
go/parser: parser to accept ~x as unary expression
7cf3268 
This is a port of CL 402255 from the syntax package to go/parser
with adjustments because of the different AST structure.

Accept ~x as ordinary unary expression in the parser but recognize
such expressions as invalid in the type checker.

This change opens the door to recognizing complex type constraint
literals such as `*E|~int` in `[P *E|~int]` and parse them correctly
instead of reporting a parse error because `P*E|~int` syntactically
looks like an incorrect array length expression (binary expression
where the RHS of | is an invalid unary expression ~int).

As a result, the parser is more forgiving with expressions but the
type checker will reject invalid uses as before.

We could pass extra information into the binary/unary expression
parse functions to prevent the use of ~ in invalid situations but
it doesn't seem worth the trouble. In fact it may be advantageous
to allow a more liberal expression syntax especially in the presence
of errors (better parser synchronization after an error).

Preparation for fixing #52559.

Change-Id: I48562cf40ccf5f14c20fcd92c40a0303b2d8b2b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/403696
Reviewed-by: Ian Lance Taylor <[email protected]>
Reviewed-by: David Chase <[email protected]>
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/404194 mentions this issue: go/printer: fix printing for possibly ambiguous type constraints

gopherbot pushed a commit that referenced this issue May 6, 2022
@griesemer
go/printer: fix printing for possibly ambiguous type constraints
5fcd1ba 
This is a port of the printer changes from CLs 402256 and 404397
in the syntax package to go/printer, with adjustments for the
different AST structure and test framework.

For #52559.

Change-Id: Ib7165979a4bd9df91f7f0f1c23b756a41ca31eb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/404194
Reviewed-by: Ian Lance Taylor <[email protected]>
Reviewed-by: Robert Findley <[email protected]>
@golang golang locked and limited conversation to collaborators Jun 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.19
Development

No branches or pull requests
3 participants
@griesemer @gopherbot @findleyr