Commit Graph

10 Commits

Author SHA1 Message Date
Argyrios Kyrtzidis
3612cd3d72 [utils/gyb_syntax_support] Add collection_element_name for when specifying a Child
This is useful to provide `add<ELEMENT_NAME>` APIs for SwiftSyntax that are better named
and without having name conflicts.
2019-04-23 18:14:39 -07:00
Xi Ge
1015a6024d Syntax: use child name instead of type name for gyb-generated functions
ParsedSyntaxBuilder has a convenient function to add member to a syntax-collection
child. The function name uses the type name of the collection's members,
which can lead to name collision. This patch renames it.
2019-04-19 18:16:13 -07:00
Xi Ge
e07a8cf2a6 SyntaxParser: set up a C API to get a hash value indicating the node declaration set
To ensure SwiftSyntax calls a compatible parser library, this patch sets
up a C API that returns a constant string calculated during compilation time to indicate
the version of syntax node declarations. The same hash will be calculated
in the SwiftSyntax (client) side as well by using the same algorithm.

During runtime, SwiftSyntax will verify its hash value is identical to the
result of calling swiftparse_node_declaration_hash before actual
parsing happens.

This patch only sets the API up. The actual implementation of the
hashing algorithm will come later.
2019-02-06 17:33:48 -08:00
Harlan
2a3d4cb598 Initial infrastructure for documenting SwiftSyntax API (#14701) 2018-02-26 13:43:11 -05:00
Rintaro Ishizaki
941cfa80bb [Syntax] Don't construct complete Syntax nodes in parsing
Instead, directly use RawSyntax.
2018-01-31 17:13:00 +09:00
Xi Ge
d927852541 libSyntax: generate condition checking code for node choices instead of hard-coding them. NFC (#13583)
This patch adds a python function to syntax node gyb support called
"check_child_condition". Given a child's definition, this function
generate a C++ closure to check whether a given syntax node can satisfy
the condition of the child node. This function recursively generates code
for node choices too, therefore we don't need to hard code the
condition checking for node choices.
2017-12-21 12:51:17 -08:00
Xi Ge
b4da5a3c31 libSyntax: use node choice for dictionary expression.
This allows us to support empty dictionary literal.
2017-12-20 18:23:23 -08:00
Xi Ge
21fc2fb92b libSyntax: use node choices for closure parameters.
This is to incorporate two styles of closure parameters: "a, b, c" or "(a:
T1, b: T2, c: T3)".
2017-12-20 18:23:23 -08:00
Xi Ge
6c1f682af9 libSyntax: allow children of syntax nodes to have multiple choices. rdar://35879331 (#13562)
Some structures of syntax nodes can have children choices, e.g. a
dictionary expression can either contain a single ':' token or a list of
key-value pairs.

This patch gives the existing code generation infrastructure a way to
specify such node choices. Node choices are specified under a child
declaration with two constraints: a choice cannot be declared as
optional, and a choice cannot have further recursive choices.

Since we don't have too many node structures with choices, part of the
SyntaxFactory code for these nodes is manually typed.

This patch also teaches AccessorBlock to use node choices.
2017-12-20 15:33:57 -08:00
Harlan
a5098e6b69 Generate libSyntax API (#10926)
* Generate libSyntax API

This patch removes the hand-rolled libSyntax API and replaces it with an
API that's entirely automatically generated. This means the API is
guaranteed to be internally stylistically and functionally consistent.
2017-07-25 18:19:58 -07:00