Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
This lookup causes recursion that the rest of the name lookup
machinery cannot yet handle, breaking code that is currently
well-formed. Back off of this lookup temporarily.
As in non-local scopes, local types and functions are generally
visible anywhere within enclosing braces, and it is up to capture
analysis to determine whether these entities attempt to capture an
entity that isn't guaranteed to be available.
While the use of a local property from within its own accessors is a
bit dubious, Swift 3 only warned on it, so model the existing lookup
behavior in the scope map.
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.
The scope map relies fairly deeply on having reasonable source ranges
for AST nodes. Fix the construction and query of source ranges in a
few places throughout the parser and AST to provide stronger
invariants.
Lazy property initializers can refer to 'self' either directly or
implicitly (via references to instance members). Model this in
ASTScope-based unqualified name lookup.
Note that the modeling of 'self' with the current name lookup
mechanism is broken, so when ASTScope-based unqualified name lookup is
enabled, it fixes SR-2203, rdar://problem/16954496, and the many dupes
of the latter.
Semantic analysis produces implicit accessors that can show up before initializers (e.g., for initializers), and it’s reasonable for ill-formed code to do this as well, so be more tolerant of ordering issues here.
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.
The scope map models all of the name lookup scopes within a source
file. It can be queried by source location to find the innermost scope
that contains that source location. Then, one can follow the parent
pointers in the scope to enumerate the enclosing scopes.
The scope map itself is lazily constructed, only creating scope map
nodes when required implicitly (e.g, when searching for a particular
innermost scope) or forced for debugging purposes.
using a lazily-constructed tree that can be searched by source
location. A search within a particular source location will
