Once top-level code is introduced into a source file, turn the source
file itself into a continuation, so that subsequent declarations have
proper scope information. This means we get proper scope information
for, e.g., pattern bindings and guard statements in top-level code, so
that a 'guard' at top level is a parent of all subsequent code,
including (e.g.) function declarations that might capture variables
introduced by the guard.
Continuations are now handled by more explicitly passing them down
from parent nodes to the child nodes that can accept them, and the
source file itself is modeled as a continuation as soon as the first
top-level code declaration is encountered.
Rather than trying to specifically model local declarations of
functions and types with a "local declaration" scope, which we
introduced when we saw one of these entities with a local DeclContext,
use a more consistency scheme where:
1) we always describe a type declaration with a TypeDecl scope and an
(abstract) function declaration with an AbstractFunctionDecl scope,
and
2) either of those scopes can steal the continuation from their
parent;
This modeling is another step toward supporting top-level code.
Record the active continuation scope for each scope. When we expand a
child node that introduces name that would be visible in a
continuation, we "steal" the continuation from the parent, so the
child takes over the responsibility of handling the continuation.
A continuation is initially introduced by expanding a brace statement,
where the continuation is itself. The eliminates a DRY violation
between the initial expansion of BraceStmts and
enumerateContinuationScopes() that's been nagging at me.
At present, this should be NFC, but it should make modeling top-level
code more reasonable.
Source range caching needs to account for the fact that the 'end'
location of various scope nodes needs to track the end of the source
file, which can grow when we're working with the REPL. Until we have
that notion, don't cache.
For methods/initializers/deinitializers, modeling the scope of a
function body allows us to correctly introduce instance member lookup
relative to 'self'. Do so so that we can resolve unqualified name
lookup within methods based on the implicit 'self'.
Introduce an operation that produces the set of local declarations
that are newly introduced by a given AST scope. This is a building
block of unqualified name lookup, which walks upward in the tree
(e.g., from children to parents) looking for declarations that have
been made visible at each step.
Consistently model all pattern bindings in the scope map, as well as
having specific nodes for their initializers. This provides us with
more consistency (the declarations are represented) as well as giving
us a scope we can use to extract the DeclContext for a non-local
initializer.
Given a source location, we can find the innermost enclosing scope
that describes that source location. Introduce this operation into the
scope map, then add a testing mode where we probe the scope map at
specifi locations to see what we find. Test for:
1) Finding the right innermost enclosing scope, and
2) That we're only expanding the part of the scope map that is needed
to identify that scope.
* A child to evaluate the conditions, which covers expressions in the conditions
* A child for the 'else' body, which does not have access to the names in the conditions
* A child for the continuation, which re-introduces the names in the conditions for the rest of the body
Now we can assert that the only out-of-order case is for accessors.
