cmd/compile: permit multiple blank type parameters (fix export data) #50481
Description
While investigating #50419, I observed a problem with the way we're indexing type parameters in export data. Consider the following type declaration:
type T[P A, _ B, _ C] int
Because we index type parameters along with other declarations in the package export data, we assign a unique name to them by prefixing with the name of the parameterized declaration, in this case, for example, "T.P" is the type parameter constrained by A. However, this schema has no way to distinguish the type parameter constrained by B and the type parameter constrained by C: both would be indexed by "T._".
Currently, our exporters are not failing, but rather choosing one of the blank type parameters to index.
Given the care required for changes to the export data, it is probably too late to fix this. Maybe we could change the indexed name for blank type parameters to something like "<prefix>.$<index>", so that the blank type parameters in the example above would be indexed as "T.$1" and "T.$2", but even that seems risky at this point.
This is unfortunate, but also should not be a significant problem for our users, since blank type parameters can always be given names. Discussing with @griesemer, we think that for Go 1.18 we should note this limitation and make it a type checking error to have multiple blank type parameters in a type or function declaration, or perhaps an error to have ANY blank names for type parameters.
Note that this limitation should NOT apply to receiver type parameters: EDIT: I spoke too soon: see #50481 (comment)func (T[_, _, _]) m() should be fine.
At some point, perhaps 1.19, we plan to increment the export data version again for the unified export data format. At that point we can lift this restriction.