cmd/compile: permit multiple blank type parameters (fix export data)

[findleyr]

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: func (T[_, _, _]) m() should be fine. EDIT: I spoke too soon: see #50481 (comment)

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.

CC @danscales @griesemer @mdempsky @ianlancetaylor

[gopherbot]

Change https://golang.org/cl/376058 mentions this issue: go/types, types2: disallow multiple blank type parameters

[griesemer]

If we accept CL 376058 then this issue can be retitled accordingly and moved to 1.19 where we should remove the restriction introduced by this CL.

[griesemer]

cc: @mdempsky (for consideration when working on 1.19 export data)

[gopherbot]

Change https://golang.org/cl/376216 mentions this issue: test/typeparam: adjust test preamble (fix longtests)

[ianlancetaylor]

If we're imposing this restriction for 1.18 be sure to note it in the release notes in the list under "The current generics implementation has the following limitations:" Thanks.

[mdempsky]

FWIW, unified IR indexes type parameters by ordinal index, not by name.

I'm interested if we have a test case that fails under the current scheme though. Because blank type parameters can't be referenced. Is the issue that the type parameters end up with the wrong constraints due to non-unique indexing?

The other quick fix is to rename blank type parameters like we do blank and anonymous (value) parameters to ~rN and ~bN.

[findleyr]

I'm interested if we have a test case that fails under the current scheme though. Because blank type parameters can't be referenced. Is the issue that the type parameters end up with the wrong constraints due to non-unique indexing?

Before the change to disallow this, it was possible to import a type parameter with incorrect constraint (only one constraint could be recorded for _). This could result in explicit instantiations that either succeed or fail where they shouldn't.

[gopherbot]

Change https://golang.org/cl/378580 mentions this issue: go/internal/gcimporter: ensure the correct constraint for blank rparams

[findleyr]

Unfortunately, it's not actually trivial to support multiple blanks on method receivers. The reason being that we need to substitute receiver type parameters in their constraints, as in the example below, and there is no such API exposed by the type checker:

type T[P any, _ *P] int

func (T[R, _]) m() {}

In this example, the constraint on the second receiver type parameter should be *R.

Therefore, even though we may have an associated constraint for receiver type parameters, there is no way to make this constraint consistent with the rest of the declaration. This may not matter much in practice, but it's incorrect.

It appears we need to either disallow multiple blanks in receiver type expressions, which would be annoying, or revisit whether or not to change the export data format.

[findleyr]

We've thought about this more, particularly in consideration of receiver type parameters (#50481 (comment)). We decided that it would be better to fix this now (as unobtrusively as possible), than to have users continually bump up against this limitation in 1.18.

This hypothetical fix proposed in #50481 (comment) is probably the least invasive change we can make: we will change the indexed name of blank type parameters from <type/function>.<method?>._ to <type/function>.<method?>.$i, where i is the index of the blank type parameter in its type parameter list. Notably, this doesn't change the layout of the export data, and doesn't change the indexed names of anything other than blank type parameters. For this reason, while this is technically a breaking change we don't think it will cause many problems.

To further smooth the roll-out of this change, we will ensure that our importers continue to support the old, ambiguous index name (T.m._).

Moved this to the 1.18 milestone, and marked as a release-blocker. We are working on it now.

CC @golang/release

[gopherbot]

Change https://golang.org/cl/379855 mentions this issue: go/internal/gcimporter: support unique naming for blank type parameters

[gopherbot]

Change https://golang.org/cl/379835 mentions this issue: Revert "doc/go1.18: document type parameter name restriction"

[danscales]

Oops, CL https://go-review.googlesource.com/c/go/+/379194 fixes this bug and should have mentioned it in the commit. We can maybe wait a few days to close this one, to make sure the compiler and tools changes all settle smoothly.

[danscales]

Builds all seem fine (including tools), closing this bug now.