go/types, types2: consider interpreting type X [P]T as generic type with missing constraint if P is not declared

[griesemer]

See #55961 for back story.

[griesemer]

The argument is that it is more likely that

type X[P] <some type literal>

where P is not defined, is a generic type declaration with missing constraint (e.g., any) rather than an array type declaration with missing array length P.

[griesemer]

cc: @mdempsky @findleyr for feedback.

[mdempsky]

This sounds reasonable to me.

One concern is how to handle follow-on errors. E.g., I think ideally go/types would only report "P is undeclared" for the package below, though even today it also reports "cannot index a (variable of type X)". So it seems okay if we instead report a spurious "cannot use X without instantiation" error.

package p

type X [P]int

var a X
var b int = a[0]

[gopherbot]

Change https://go.dev/cl/439476 mentions this issue: go/types, types2: better error for generic type decl. with missing constraint

[gopherbot]

Change https://go.dev/cl/439559 mentions this issue: go/types, types2: better error for generic type decl. with missing constraint

[griesemer]

Per discussion on the CL, while it's not hard to interpret an array declaration with an undefined length identifier as a generic type declaration with a missing type constraint, the re-interpretation leads to incorrect population of the various type-checker maps used by tools. Instead, opt for a better error message about the invalid array length.