Variable declarations are declarations led by either 'var' or 'let'. It
can contain multiple pattern bindings as children.
For patterns, this patch only creates syntax nodes for simple identifier
patterns, e.g. 'a = 3'. The rest of the pattern kinds are still left
unknown (UnknownPattern).
This document breaks all existing syntactic AST nodes into five categories:
expression, declaration, statement, pattern and typerepr. Nodes in each
category can be further defined as "specialized", "in-progress" and
"not-specialized".
The parser currently can recognize specialized nodes; for "in-progress"
and "not-specialized" nodes, the parser will wrap their underlying source
to be an unknown entity, e.g. UnknownDecl or UnknownStmt.
"in-progress" nodes are considered in a higher priority to be specialized
than "not-specialized" nodes. However, eventually all nodes should be
marked as "specialized".
to check text-choices of a token child.
This allows us to reject the creation of a syntax node if one of its token
syntax children doesn't follow the required textual choices, e.g.
modifiers.
To construct struct syntax, this patch first specialized type
inheritance clause. For protocol's class requirement, we currently
treat it as an unknown type.
This patch also teaches SyntaxParsingContext to collect syntax nodes
from back in place. This is useful to squash multiple decl modifiers
for declarations like function. This is not used for struct declaration
because only accessibility modifier is allowed.
This patch also performs minor refactoring to align syntax parsing
context with the right scope. We start to support the generic clauses
because they are necessary pieces to construct struct or
function syntax node.
Because generic where clause doesn't coerce well to our existing syntax
context kinds, we add a new syntax context kind with this patch called
"Syntax". This context kind indicates that when error occurs, the
collection of syntax nodes falling into the context should be coerced
to UnknownSyntax.
* libSyntax: Parse member access expression.
This patch uses createNodeInPlace from syntax parsing context API to
merge an expression with its suffix to create recursive nodes such as
member access expression.
Meanwhile, this patch breaks down a signed integer or float literal to a
prefix operator expression. This expression consists of two parts: an
operator and the following expression. This makes literals like "+1" or
"-1" no different from other prefix unary expressions such as "!true".
Along with starting to support ternary expressions, this commit also
slightly changes SyntaxParsingContext APIs as follows:
1. Previously, makeNode() only supports node creation by using the nodes
from the underlying syntax token array; this commit allows it to use the nodes from
the pending syntax list as well.
2. This commit strictly limits that the pending syntax list should never
contain token syntax node.
3. The node kind test shouldn't include unknown kinds. They are noisy.
Avoid heap-allocated memory for syntax parsing context.
Add more assertions to ensure syntax nodes are created only at the top of context stack.
Allow syntax parsing context to delay the specifying of context kind and target syntax kind.
This commit also adds ArrayExpr and DictionaryExpr to the libSyntax nodes
family. Also, it refactors the original parser code for these two
expressions to better fit to the design of SyntaxParsingContext.
This commit has also fixed two crashers.
This commit teaches parser to parse two libSyntax nodes: FunctionCallArgument and
FunctionCallArgumentList. Along with the change, some libSyntax parsing infrastructure changes
as well: (1) parser doesn't directly insert token into the buffer for libSyntax node creation;
instead, when creating a simple libSyntax node like integer literal expression, parser should indicate the location of the last token in the node; (2) implicit libSyntax nodes like empty
statement list must contain a source location indicating where the implicit nodes should appear
(immediately before the token at the given location).
This commit teaches parser to generate code block syntax node. As a support for this,
SyntaxParsingContext can be created by a single syntax kind, indicating the whole context
should be parsed into a node of that given syntax. Another change is to bridge created syntax
node with the given context kind. For instance, if a statement context results into an expression
node, the expression node will be bridged to a statement by wrapping it with a ExpressionStmt
node.
* Re-apply "libSyntax: Ensure round-trip printing when we build syntax tree from parser incrementally. (#12709)"
* Re-apply "libSyntax: Root parsing context should hold a reference to the current token in the parser, NFC."
* Re-apply "libSyntax: avoid copying token text when lexing token syntax nodes, NFC. (#12723)"
* Actually fix the container-overflow issue.
Since all parsing contexts need a reference to the current token of the
parser, we should pass the token reference to the root context. Therefore, the derived
sub-contexts can just copy it while being spawned.
