Skip to content

go/types: expose interface satisfaction constraints #8970

@adonovan

Description

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    RefactoringIssues related to refactoring tools

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions