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.
