Only use the existing type checker (via "TC") in the iterative type
checker when we're actually making use of its functionality. The
intent is to drive this usage down to zero as we port code over to the
iterative type checker, so unprincipled uses get in the way.
Swift SVN r32573
Put in some rudimentary logic for finding circular references within
the iterative type checker and diagnosing those cycles. The
"rudimentary" part is because we're performing linear searches within
a stack rather than keeping a proper dependency graph, which is
inefficient and could display longer cycles than are actually
present. Additionally, the diagnostic is not specialized to the actual
query, so we get a generic "circular reference" diagnostic. OTOH, we
show all of the declarations involved in the cycle, which at least
lets the user figure out where the cycle occurred.
Enable the iterative type checker for resolving the type of a global
typealiases.
Swift SVN r32572
The separate "enumerate dependencies" and "satisfy" phases didn't make
sense, because one often needs to process part of a request to enumerate
additional dependencies. Collapse these two phases into a single
"process" operation that makes what progress it can, and enumerates
additional dependencies that need to be satisfied before it can
progress further.
Swift SVN r32563
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
