Navigation Menu

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

Jump to bottom

go/types: expose interface satisfaction constraints #8970

Open
adonovan opened this issue Oct 20, 2014 · 6 comments
Open

go/types: expose interface satisfaction constraints #8970

adonovan opened this issue Oct 20, 2014 · 6 comments
Labels
Refactoring Issues related to refactoring tools
Milestone
Unreleased

Comments

@adonovan
Copy link
Member 

The type checker goes to very great lengths to be robust and precise even for ill-typed
inputs, and it is very hard to match this level of robustness in other passes over the
(typed) AST.  As a result, the refactor/lexical and refactor/satisfy packages, both of
which recompute information computed but not exposed by go/types, are not safe to run on
programs with type errors.

refactor/lexical records, for every referring identifier, the structure of the lexical
environment at that point, information that is necessary for refactoring tools and
impossible to derive from the Scope information currently exposed by the type checker
(which is rarely useful).

refactor/satisfies records the set of type pairs (x, y) such that x is assignable to
interface y, and if it were not assignable, the program would not compile.  This also is
necessary for refactoring tools.

I think the 'lexical' pass could be very cheaply and elegantly implemented into the
existing type checker, and I think it should be since it is so useful; 'satisfies' is 
trickier.
@ianlancetaylor
Copy link
Contributor

Comment 1:

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

@bradfitz bradfitz removed the new label Dec 18, 2014
@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: expose precise lexical scope information in API; also interface satisfaction constraints x/tools/go/types: expose precise lexical scope information in API; also interface satisfaction constraints 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: expose precise lexical scope information in API; also interface satisfaction constraints go/types: expose precise lexical scope information in API; also interface satisfaction constraints Jul 31, 2015
@alandonovan
Copy link
Contributor

Update: the refactor/lexical half of this issue was fixed by https://go-review.googlesource.com/10800
(and refactor/lexical was deleted). The refactor/satisfies part remains.

@alandonovan alandonovan changed the title go/types: expose precise lexical scope information in API; also interface satisfaction constraints go/types: expose interface satisfaction constraints Feb 11, 2016
@griesemer
Copy link
Contributor

@alandonovan Please comment on this issue if you still think this is useful and explain what kind of API you'd suggest. Otherwise, feel free to close it. Thanks.

@alandonovan
Copy link
Contributor

Here's a straw-man go/types API that would let us evaluate whether a small change to the implementation would eliminate the refactor/satisfies package:

We add a new field, Satisfies [][2]Type, to the Info struct. If this field is non-nil (even if empty), the client is assumed to want the extra information. Each time we call operand.assignableTo(x, T) where T is an non-empty interface type, x.typ is not identical to T, and the call returns true, we append a pair (x.typ, T) to the Satisfies slice.

The only change to assignableTo would be within the case documented as "T is an interface type and x implements T". A pointer to the Satisfies slice would be passed in, with nil meaning "don't record the information" as in the case where assignableTo is called from the public AssignableTo function.

I guess I should prototype this myself.

@griesemer
Copy link
Contributor

@alandonovan Seems fine to me implementation-wise. But as described, this will only record pair combinations that appeared in the type-checked code. Is that sufficient?

@alandonovan
Copy link
Contributor

Yes, that's sufficient. Users can already compute assignability for arbitrary pairs of types; what's missing is knowing which types' assignability mattered to a particular package.

@adonovan adonovan added the Refactoring Issues related to refactoring tools label Apr 24, 2023
@adonovan adonovan mentioned this issue Sep 6, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Refactoring Issues related to refactoring tools
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
6 participants
@bradfitz @rsc @ianlancetaylor @adonovan @alandonovan @griesemer