go/types: Info.Selections records unique objects for generic methods

[dominikh]

Consider https://gotipplay.golang.org/p/DBMZ9zBIaGB

We have a generic and a normal method named Bar, which result in the following two objects in Info.Defs:

def: Bar = func (pkg.Generic[T]).Bar() [0xc0000699a0]
def: Bar = func (pkg.Normal).Bar() [0xc000069b30]

All calls to Normal.Bar map to the same object in Info.Selections, which is also the object that was recorded in Info.Defs:

use: &{recv Bar} = func (pkg.Normal).Bar() [0xc000069b30]
use: &{recv Bar} = func (pkg.Normal).Bar() [0xc000069b30]
use: &{recv Bar} = func (pkg.Normal).Bar() [0xc000069b30]

However, each call to Generic[T].Bar maps to a different object, none of which matches one in Info.Defs:

use: &{recv Bar} = func (pkg.Generic[T]).Bar() [0xc00013e280]
use: &{recv Bar} = func (pkg.Generic[T]).Bar() [0xc00013e370]
use: &{recv Bar} = func (pkg.Generic[T]).Bar() [0xc00013e460]

(The same behavior can be observed with Info.Uses instead of Info.Selections.)

Is this expected behavior?

/cc @findleyr

[findleyr]

@dominikh yes, this is expected (but rather subtle) behavior. This is also discussed in https://go.dev/issue/50619.

Methods on generic types are a bit strange by construction: their receiver base cannot be the generic type, because we don't allow uses of uninstantated generic types. Instead, the receiver base type is the generic type instantiated with the method's receiver type parameters.

Because we made the decision to have a 1:1 correspondence between type parameter names and type parameter types (for the purpose of better type strings), the receiver type parameters of each method are distinct types. So this means that the receiver base of each method has a distinct identity, and yes, that we have a theoretical N^2 fan-out of methods on a generic type: each method has a distinct instance as its receiver, and each receiver therefore has a distinct method set. Though note that methods are lazily instantiated when they are used.

I believe this is logically consistent, but certainly subtle. For this reason, I hope to upstream helpers like OriginMethod to go/types.

[dominikh]

Thanks for the clarification. That is certainly something for internal/typeparams/example :)

I'm going to close this issue as there doesn't seem to be anything to do here.