go: syntax: parser doesn't recognize valid type parameter list
There is a (known) ambiguity for type parameter lists. For
type T[P *int] struct{}
the parser cannot tell if this is a generic type declaration or an array type declaration with length P*int
. In general, people will write ~*int
and there is the work-around interface{*int}
; one just has to be aware of it.
But the parser also assumes that
type T[P *int, Q any] struct{}
is starting an array type declaration, yet this is clearly a valid type parameter list.
Should be fixed for 1.18 but is not a release blocker as there are work-arounds.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 16 (8 by maintainers)
Commits related to this issue
- spec: describe constraint parsing ambiguity and work-around more precisely The new description matches the implementation (CL 370774). Also, in the section on type constraints, use "defines" instead... — committed to golang/go by griesemer 3 years ago
- go/parser, go/printer: fix parsing of ambiguous type parameter lists This is a port of CL 370774 to go/parser and go/printer. It is adjusted for the slightly different factoring of parameter list par... — committed to golang/go by findleyr 2 years ago
- go/types, types2: add tests for literals in type parameter lists Add tests that verify consistent behavior of go/types and types2 with respect to potentially ambiguous type parameter lists. For #494... — committed to golang/go by findleyr 2 years ago
- cmd/compile/internal/syntax: parser to accept ~x as unary expression Accept ~x as ordinary unary expression in the parser but recognize such expressions as invalid in the type checker. This change o... — committed to golang/go by griesemer 2 years ago
- cmd/compile/internal/syntax: fix printing of ambiguous constraint literals Without this change, the type parameter list "[P T | T]" is printed as "[P T | T,]" in an attempt to avoid an ambiguity. But... — committed to golang/go by griesemer 2 years ago
Thanks to @mdempsky’s help, we landed the fix to make
go/parser
andgo/printer
consistent with the compiler. Moved this to 1.19, when we can consider further improvements to our parsing of ambiguous type parameter lists.CC @golang/release @mdempsky
As mentioned above, I think this may be a release blocker. Since the CL is mailed, I have added the release-blocker label in hopes that it can get merged before the RC1. Please reach out to me if any concerns.