syntax: parser doesn't recognize valid type parameter list

[griesemer]

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.

cc: @findleyr @ianlancetaylor

[griesemer]

Another work-around for the single type-parameter case would be a trailing comma, as in

type T[P *int,] struct{}

because type parameter lists (like all parameter lists) permit a trailing comma, while array type declarations don't.

[ianlancetaylor]

I assume that this also works:

type T[P (*int)] struct{}

[griesemer]

It should but currently doesn't, it appears. Filed a separate issue #49485.

[griesemer]

It turns out that using parentheses does not work in general.

[gopherbot]

Change https://golang.org/cl/370774 mentions this issue: cmd/compile/internal/parser: fix parsing of type parameter lists

[gopherbot]

Change https://golang.org/cl/372874 mentions this issue: spec: describe constraint parsing ambiguity and work-around more precisely

[gopherbot]

Change https://go.dev/cl/385575 mentions this issue: go/parser, go/printer: fix parsing of ambiguous type parameter lists

[findleyr]

Reopening as while auditing our port sheet I realized this fix did not get ported to go/parser. I have mailed the port in https://go.dev/cl/385575. Tentatively marking as a release blocker: the original bug may not have been a release blocker, but it seems like a release blocker that the compiler accepts these expressions and go/parser does not, even if they will be uncommon in practice.

[findleyr]

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.

[findleyr]

While working on the port, I realized that there are valid cases that both parsers can't currently handle. For example:

type _[P *struct{}|int] struct{}  // example 1
type _[P *struct{}|~int] struct{}  // example 2

Example 1 is parsed as an array type, though it can be unambiguously parsed as a generic type declaration. Example 2 is a parser error.

I have a fix for both cases, but since this is not trivial I think it must wait until Go 1.19. I believe the CL above makes go/parser bug-compatible with the compiler.

[gopherbot]

Change https://go.dev/cl/385756 mentions this issue: go/types, types2: add tests for literals in type parameter lists

[gopherbot]

Change https://go.dev/cl/385757 mentions this issue: go/parser: fix parsing of unambiguous type parameter lists

[findleyr]

Thanks to @mdempsky's help, we landed the fix to make go/parser and go/printer consistent with the compiler. Moved this to 1.19, when we can consider further improvements to our parsing of ambiguous type parameter lists.

[gopherbot]

Change https://go.dev/cl/402255 mentions this issue: cmd/compile/internal/syntax: parser to accept ~x as unary expression

[gopherbot]

Change https://go.dev/cl/402256 mentions this issue: cmd/compile/internal/syntax: accept all valid type parameter lists

[gopherbot]

Change https://go.dev/cl/404397 mentions this issue: cmd/compile/internal/syntax: fix printing of ambiguous constraint literals