go/types: maintain "owner" information for interface methods and struct fields

[adonovan]

Hi Robert,

in our indexer for Go, when we load (from export data) a package that defines types such
as the following:

    type T struct { X int }
    type U T
    type S U

there is nothing in the go/types API that allows the client to determine that although
the *types.Var for X is a member of S, T and U, it was originally declared beneath T. 
(Underlying() returns the same struct type for S, T and U.)

An analogous situation holds for interface methods:

   type Closer interface { func Close() error }
   type WriterCloser interface { Writer; Closer }

i.e. there is no record of the fact that the Close() method was originally declared
beneath Closer, not WriterCloser.

The indexer needs this information because it must invent a globally unique stable name
for T.X that relates its definition in this package to its uses in other packages. 
Right now, it picks---consistently but arbitrarily---the lexicographically least name
from the set {S.X, T.X, U.X}, i.e. S.X.  So long as all invocations of go/types use
export data that includes S, then all will use the same least name S.X.  However, if the
package was loaded from partial export data that does not include the least name, the
result is a dangling link.

What the indexer needs is that go/types expose some information about the field X that
allows us to come up with a stable name for it each time we encounter it across
different invocations of the type checker.  Associating X with its "true"
owner (T.X) is the most logical approach and will doubtless have benefits for other
applications, but any stable name could work (e.g. the least name, or some fingerprint).

So: how should we do this?

[griesemer]

Comment 1:

Labels changed: added release-none, repo-tools.

Status changed to Thinking.

[griesemer]

@adonovan Is this still of interest? If so, please comment on this issue and mark for 1.11, "early in cycle" and I'll try to address it. Thanks.