Implement some awful, *recursive* code in the *iterative* type checker
that satisfies all of the dependencies of a type check request
(*recursively*) before satisfying the type check request itself. This
is placeholder code that lets us flesh out the dependency mechanism
separately from implementing the proper data structures.
To test this, implement a type check request for type-checking one
type within an inheritance clause. Make the superclass type check
request depend on the first type in the inheritance clause of the
class, with a recovery path that looks at subsequent types in the
inheritance clause so long as we're still seeing protocol types. This
checking is more minimal than what we were doing previously (where we
would check all of the inherited types to find the superclass) and a
simple illustration of dependencies that can evolve.
Swift SVN r32559
This is all effectively NFC, but lays out the shape of the iterative
type checker: requests are packaged up in TypeCheckRequest, we can
check whether the request has been satisfied already (isSatisfied),
enumerate its dependencies (enumerateDependenciesOf) in terms of other
TypeCheckRequests, and satisfy a request (satisfy).
Lazily-computed semantic information is captured directly in the
AST, but has been set aside in its own structure to allow us to
experiment with moving it into a lookaside table.
The only request that exists now is to type-check the superclass of
the given class. It currently performs unhealthy recursion into the
existing type checker. As we detangle dependencies, this recursion
between the IterativeTypeChecker and the TypeChecker can go away.
Swift SVN r32558
