Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
adonovan opened this issue Jun 10, 2014 · 2 comments

Comments

Projects
None yet
3 participants
@adonovan
Copy link

commented Jun 10, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2014

Comment 1:

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

Status changed to Thinking.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed the release-none label Apr 10, 2015

@rsc rsc changed the title go/types: maintain "owner" information for interface methods and struct fields x/tools/go/types: maintain "owner" information for interface methods and struct fields Apr 14, 2015

@rsc rsc modified the milestones: Unreleased, Unplanned Apr 14, 2015

@rsc rsc removed the repo-tools label Apr 14, 2015

@griesemer griesemer changed the title x/tools/go/types: maintain "owner" information for interface methods and struct fields go/types: maintain "owner" information for interface methods and struct fields Jul 31, 2015

@griesemer griesemer added NeedsDecision and removed Thinking labels Dec 20, 2017

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Dec 20, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.