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.