Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
go/types: expose interface satisfaction constraints #8970
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.
changed the title
go/types: expose precise lexical scope information in API; also interface satisfaction constraints
Apr 14, 2015
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 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.