Rework the lazy function body parsing mechanism to use the
request-evaluator, so that asking for the body of a function will
initiate parsing. Clean up a number of callers to
AbstractFunctionDecl::getBody() that don't actually need the body, so
we don't perform unnecessary parsing.
This change does not delay parsing of function bodies in the general
case; rather, it sets up the infrastructure to always delay parsing of
function bodies.
Lazy parsing for the members of nominal types and extensions depends
only on information already present in
`IterableDeclContext`. Eliminate the use of PersistentParserState as
an intermediary and have the member-parsing request construct a new
`Parser` instance itself to handle parsing. Make this possible even
for ill-formed nominal types/extensions to simplify the code path.
Eliminate `LazyMemberParser` and all of its uses, because it was only
present for lazy member parsing, which no longer needs it.
The `DelayedDeclKind` structure that's allocated for each case where
we delay parsing the members of a nominal type definition or extension
contains information that is already available on the
`IterableDeclContext` (or can be reconstructed trivially from it). Use
that AST information rather than this side structure.
Ensure that lazy parsing of the members of nominal type definitions
and extensions is handled through a request. Most of the effort here
is in establishing a new request zone for parser requests.
Instead of creating the AST directly in the parser (and libSyntax or
SwiftSyntax via SyntaxParsingContext), make Parser to explicitly create
a tree of ParsedSyntaxNodes. Their OpaqueSyntaxNodes can be either
libSyntax or SwiftSyntax. If AST is needed, it can be generated from the
libSyntax tree.
To properly delay parsing type and extension bodies we need to know
which ones might contain nested operator and class definitions, since
they must be known upfront when building the global operator lookup
and AnyObject dispatch lookup tables, respectively.
To guess if the type contains operator definitions, we look for the
'func' keyword followed by an operator token.
To guess if the type contains class definitions, we look for the
'class' keyword.
For now, this information is recorded but not used. Subsequent commits
will make use of this information to delay parsing in more cases.
SyntaxParseActions::recordToken() et al. may return the same pointer
value for different nodes (e.g. `nullptr`). So we cannot use DenseMap to
associate the node from the explicit syntax parsing actions to libSyntax
node. Instead, use a structure that wraps them.
- When parsing a type or extension declaration, attempt to parse a function or property declaration when meeting an identifier, an operator or a paren (for tuple declarations).
- Produce the diagnostic with a fix-it suggesting to insert the needed keyword
- Recover parsing as if the declaration with the missing keyword is a function/property declaration
Resolves https://bugs.swift.org/browse/SR-10477
Instead of creating the AST directly in the parser (and libSyntax or
SwiftSyntax via SyntaxParsingContext), make Parser to explicitly create
a tree of ParsedSyntaxNodes. Their OpaqueSyntaxNodes can be either
libSyntax or SwiftSyntax. If AST is needed, it can be generated from the
libSyntax tree.
In parser, 'parseExprPostfixSuffix()' can parse postfix expression for
'super'. 'parseExprSuper()' doesn't need to parse them.
In code-completion, 'completeExprSuper()' and 'completeExprSuperDot()'
can be consolidated to 'completePostfixExpr()' and 'completeDotExpr()'.
