Document the new query syntax
This commit is contained in:
Max Brunsfeld
parent
68f43b5865
commit
f6f96f3503
1 changed files with 117 additions and 81 deletions
|
|
@ -24,19 +24,22 @@ script/build-lib
|
|||
Alternatively, you can use the library in a larger project by adding one source file to the project. This source file needs two directories to be in the include path when compiled:
|
||||
|
||||
**source file:**
|
||||
* `tree-sitter/lib/src/lib.c`
|
||||
|
||||
- `tree-sitter/lib/src/lib.c`
|
||||
|
||||
**include directories:**
|
||||
* `tree-sitter/lib/src`
|
||||
* `tree-sitter/lib/include`
|
||||
|
||||
- `tree-sitter/lib/src`
|
||||
- `tree-sitter/lib/include`
|
||||
|
||||
### The Basic Objects
|
||||
|
||||
There are four main types of objects involved when using Tree-sitter: languages, parsers, syntax trees, and syntax nodes. In C, these are called `TSLanguage`, `TSParser`, `TSTree`, and `TSNode`.
|
||||
* A `TSLanguage` is an opaque object that defines how to parse a particular programming language. The code for each `TSLanguage` is generated by Tree-sitter. Many languages are already available in separate git repositories within the the [Tree-sitter GitHub organization](https://github.com/tree-sitter). See [the next page](./creating-parsers) for how to create new languages.
|
||||
* A `TSParser` is a stateful object that can be assigned a `TSLanguage` and used to produce a `TSTree` based on some source code.
|
||||
* A `TSTree` represents the syntax tree of an entire source code file. It contains `TSNode` instances that indicate the structure of the source code. It can also be edited and used to produce a new `TSTree` in the event that the source code changes.
|
||||
* A `TSNode` represents a single node in the syntax tree. It tracks its start and end positions in the source code, as well as its relation to other nodes like its parent, siblings and children.
|
||||
|
||||
- A `TSLanguage` is an opaque object that defines how to parse a particular programming language. The code for each `TSLanguage` is generated by Tree-sitter. Many languages are already available in separate git repositories within the the [Tree-sitter GitHub organization](https://github.com/tree-sitter). See [the next page](./creating-parsers) for how to create new languages.
|
||||
- A `TSParser` is a stateful object that can be assigned a `TSLanguage` and used to produce a `TSTree` based on some source code.
|
||||
- A `TSTree` represents the syntax tree of an entire source code file. It contains `TSNode` instances that indicate the structure of the source code. It can also be edited and used to produce a new `TSTree` in the event that the source code changes.
|
||||
- A `TSNode` represents a single node in the syntax tree. It tracks its start and end positions in the source code, as well as its relation to other nodes like its parent, siblings and children.
|
||||
|
||||
### An Example Program
|
||||
|
||||
|
|
@ -128,7 +131,7 @@ TSTree *ts_parser_parse_string(
|
|||
);
|
||||
```
|
||||
|
||||
You may want to parse source code that's stored in a custom data structure, like a [piece table](https://en.wikipedia.org/wiki/Piece_table) or a [rope](https://en.wikipedia.org/wiki/Rope_(data_structure)). In this case, you can use the more general `ts_parser_parse` function:
|
||||
You may want to parse source code that's stored in a custom data structure, like a [piece table](https://en.wikipedia.org/wiki/Piece_table) or a [rope](<https://en.wikipedia.org/wiki/Rope_(data_structure)>). In this case, you can use the more general `ts_parser_parse` function:
|
||||
|
||||
```c
|
||||
TSTree *ts_parser_parse(
|
||||
|
|
@ -155,7 +158,7 @@ typedef struct {
|
|||
|
||||
### Syntax Nodes
|
||||
|
||||
Tree-sitter provides a [DOM](https://en.wikipedia.org/wiki/Document_Object_Model)-style interface for inspecting syntax trees. A syntax node's *type* is a string that indicates which grammar rule the node represents.
|
||||
Tree-sitter provides a [DOM](https://en.wikipedia.org/wiki/Document_Object_Model)-style interface for inspecting syntax trees. A syntax node's _type_ is a string that indicates which grammar rule the node represents.
|
||||
|
||||
```c
|
||||
const char *ts_node_type(TSNode);
|
||||
|
|
@ -178,7 +181,7 @@ TSPoint ts_node_end_point(TSNode);
|
|||
|
||||
### Retrieving Nodes
|
||||
|
||||
Every tree has a *root node*:
|
||||
Every tree has a _root node_:
|
||||
|
||||
```c
|
||||
TSNode ts_tree_root_node(const TSTree *);
|
||||
|
|
@ -199,7 +202,7 @@ TSNode ts_node_prev_sibling(TSNode);
|
|||
TSNode ts_node_parent(TSNode);
|
||||
```
|
||||
|
||||
These methods may all return a *null node* to indicate, for example, that a node does not *have* a next sibling. You can check if a node is null:
|
||||
These methods may all return a _null node_ to indicate, for example, that a node does not _have_ a next sibling. You can check if a node is null:
|
||||
|
||||
```c
|
||||
bool ts_node_is_null(TSNode);
|
||||
|
|
@ -207,21 +210,15 @@ bool ts_node_is_null(TSNode);
|
|||
|
||||
### Named vs Anonymous Nodes
|
||||
|
||||
Tree-sitter produces [*concrete* syntax trees](https://en.wikipedia.org/wiki/Parse_tree) - trees that contain nodes for every individual token in the source code, including things like commas and parentheses. This is important for use-cases that deal with individual tokens, like [syntax highlighting](https://en.wikipedia.org/wiki/Syntax_highlighting). But some types of code analysis are easier to perform using an [*abstract* syntax tree](https://en.wikipedia.org/wiki/Abstract_syntax_tree) - a tree in which the less important details have been removed. Tree-sitter's trees support these use cases by making a distinction between *named* and *anonymous* nodes.
|
||||
Tree-sitter produces [_concrete_ syntax trees](https://en.wikipedia.org/wiki/Parse_tree) - trees that contain nodes for every individual token in the source code, including things like commas and parentheses. This is important for use-cases that deal with individual tokens, like [syntax highlighting](https://en.wikipedia.org/wiki/Syntax_highlighting). But some types of code analysis are easier to perform using an [_abstract_ syntax tree](https://en.wikipedia.org/wiki/Abstract_syntax_tree) - a tree in which the less important details have been removed. Tree-sitter's trees support these use cases by making a distinction between _named_ and _anonymous_ nodes.
|
||||
|
||||
Consider a grammar rule like this:
|
||||
|
||||
```js
|
||||
if_statement: $ => seq(
|
||||
'if',
|
||||
'(',
|
||||
$._expression,
|
||||
')',
|
||||
$._statement,
|
||||
)
|
||||
if_statement: ($) => seq("if", "(", $._expression, ")", $._statement);
|
||||
```
|
||||
|
||||
A syntax node representing an `if_statement` in this language would have 5 children: the condition expression, the body statement, as well as the `if`, `(`, and `)` tokens. The expression and the statement would be marked as *named* nodes, because they have been given explicit names in the grammar. But the `if`, `(`, and `)` nodes would *not* be named nodes, because they are represented in the grammar as simple strings.
|
||||
A syntax node representing an `if_statement` in this language would have 5 children: the condition expression, the body statement, as well as the `if`, `(`, and `)` tokens. The expression and the statement would be marked as _named_ nodes, because they have been given explicit names in the grammar. But the `if`, `(`, and `)` nodes would _not_ be named nodes, because they are represented in the grammar as simple strings.
|
||||
|
||||
You can check whether any given node is named:
|
||||
|
||||
|
|
@ -242,7 +239,7 @@ If you use this group of methods, the syntax tree functions much like an abstrac
|
|||
|
||||
### Node Field Names
|
||||
|
||||
To make syntax nodes easier to analyze, many grammars assign unique *field names* to particular child nodes. The next page [explains](./creating-parsers#using-fields) how to do this on your own grammars. If a syntax node has fields, you can access its children using their field name:
|
||||
To make syntax nodes easier to analyze, many grammars assign unique _field names_ to particular child nodes. The next page [explains](./creating-parsers#using-fields) how to do this on your own grammars. If a syntax node has fields, you can access its children using their field name:
|
||||
|
||||
```c
|
||||
TSNode ts_node_child_by_field_name(
|
||||
|
|
@ -270,7 +267,7 @@ TSNode ts_node_child_by_field_id(TSNode, TSFieldId);
|
|||
|
||||
### Editing
|
||||
|
||||
In applications like text editors, you often need to re-parse a file after its source code has changed. Tree-sitter is designed to support this use case efficiently. There are two steps required. First, you must *edit* the syntax tree, which adjusts the ranges of its nodes so that they stay in sync with the code.
|
||||
In applications like text editors, you often need to re-parse a file after its source code has changed. Tree-sitter is designed to support this use case efficiently. There are two steps required. First, you must _edit_ the syntax tree, which adjusts the ranges of its nodes so that they stay in sync with the code.
|
||||
|
||||
```c
|
||||
typedef struct {
|
||||
|
|
@ -293,13 +290,13 @@ When you edit a syntax tree, the positions of its nodes will change. If you have
|
|||
void ts_node_edit(TSNode *, const TSInputEdit *);
|
||||
```
|
||||
|
||||
This `ts_node_edit` function is *only* needed in the case where you have retrieved `TSNode` instances *before* editing the tree, and then *after* editing the tree, you want to continue to use those specific node instances. Often, you'll just want to re-fetch nodes from the edited tree, in which case `ts_node_edit` is not needed.
|
||||
This `ts_node_edit` function is _only_ needed in the case where you have retrieved `TSNode` instances _before_ editing the tree, and then _after_ editing the tree, you want to continue to use those specific node instances. Often, you'll just want to re-fetch nodes from the edited tree, in which case `ts_node_edit` is not needed.
|
||||
|
||||
### Multi-language Documents
|
||||
|
||||
Sometimes, different parts of a file may be written in different languages. For example, templating languages like [EJS](http://ejs.co) and [ERB](https://ruby-doc.org/stdlib-2.5.1/libdoc/erb/rdoc/ERB.html) allow you to generate HTML by writing a mixture of HTML and another language like JavaScript or Ruby.
|
||||
|
||||
Tree-sitter handles these types of documents by allowing you to create a syntax tree based on the text in certain *ranges* of a file.
|
||||
Tree-sitter handles these types of documents by allowing you to create a syntax tree based on the text in certain _ranges_ of a file.
|
||||
|
||||
```c
|
||||
typedef struct {
|
||||
|
|
@ -409,13 +406,13 @@ Tree-sitter supports multi-threaded use cases by making syntax trees very cheap
|
|||
TSTree *ts_tree_copy(const TSTree *);
|
||||
```
|
||||
|
||||
Internally, copying a syntax tree just entails incrementing an atomic reference count. Conceptually, it provides you a new tree which you can freely query, edit, reparse, or delete on a new thread while continuing to use the original tree on a different thread. Note that individual `TSTree` instances are *not* thread safe; you must copy a tree if you want to use it on multiple threads simultaneously.
|
||||
Internally, copying a syntax tree just entails incrementing an atomic reference count. Conceptually, it provides you a new tree which you can freely query, edit, reparse, or delete on a new thread while continuing to use the original tree on a different thread. Note that individual `TSTree` instances are _not_ thread safe; you must copy a tree if you want to use it on multiple threads simultaneously.
|
||||
|
||||
## Other Tree Operations
|
||||
|
||||
### Walking Trees with Tree Cursors
|
||||
|
||||
You can access every node in a syntax tree using the `TSNode` APIs [described above](#retrieving-nodes), but if you need to access a large number of nodes, the fastest way to do so is with a *tree cursor*. A cursor is a stateful object that allows you to walk a syntax tree with maximum efficiency.
|
||||
You can access every node in a syntax tree using the `TSNode` APIs [described above](#retrieving-nodes), but if you need to access a large number of nodes, the fastest way to do so is with a _tree cursor_. A cursor is a stateful object that allows you to walk a syntax tree with maximum efficiency.
|
||||
|
||||
You can initialize a cursor from any node:
|
||||
|
||||
|
|
@ -441,19 +438,19 @@ const char *ts_tree_cursor_current_field_name(const TSTreeCursor *);
|
|||
TSFieldId ts_tree_cursor_current_field_id(const TSTreeCursor *);
|
||||
```
|
||||
|
||||
### Pattern Matching with Queries
|
||||
## Pattern Matching with Queries
|
||||
|
||||
Many code analysis tasks involve searching for patterns in syntax trees. Tree-sitter provides a small declarative language for expressing these patterns and searching for matches. The language is similar to the format of Tree-sitter's [unit test system](./creating-parsers#command-test).
|
||||
|
||||
#### Basics
|
||||
### Query Syntax
|
||||
|
||||
A *query* consists of one or more *patterns*, where each pattern is an [S-expression](https://en.wikipedia.org/wiki/S-expression) that matches a certain set of nodes in a syntax tree. The expression to match a given node consists of a pair of parentheses containing two things: the node's type, and optionally, a series of other S-expressions that match the node's children. For example, this pattern would match any `binary_expression` node whose children are both `number_literal` nodes:
|
||||
A _query_ consists of one or more _patterns_, where each pattern is an [S-expression](https://en.wikipedia.org/wiki/S-expression) that matches a certain set of nodes in a syntax tree. The expression to match a given node consists of a pair of parentheses containing two things: the node's type, and optionally, a series of other S-expressions that match the node's children. For example, this pattern would match any `binary_expression` node whose children are both `number_literal` nodes:
|
||||
|
||||
```
|
||||
(binary_expression (number_literal) (number_literal))
|
||||
```
|
||||
|
||||
Children can also be omitted. For example, this would match any `binary_expression` where at least *one* of child is a `string_literal` node:
|
||||
Children can also be omitted. For example, this would match any `binary_expression` where at least _one_ of child is a `string_literal` node:
|
||||
|
||||
```
|
||||
(binary_expression (string_literal))
|
||||
|
|
@ -481,13 +478,13 @@ The parenthesized syntax for writing nodes only applies to [named nodes](#named-
|
|||
|
||||
#### Capturing Nodes
|
||||
|
||||
When matching patterns, you may want to process specific nodes within the pattern. Captures allow you to associate names with specific nodes in a pattern, so that you can later refer to those nodes by those names. Capture names are written *after* the nodes that they refer to, and start with an `@` character.
|
||||
When matching patterns, you may want to process specific nodes within the pattern. Captures allow you to associate names with specific nodes in a pattern, so that you can later refer to those nodes by those names. Capture names are written _after_ the nodes that they refer to, and start with an `@` character.
|
||||
|
||||
For example, this pattern would match any assignment of a `function` to an `identifier`, and it would associate the name `function-definition` with the identifier:
|
||||
For example, this pattern would match any assignment of a `function` to an `identifier`, and it would associate the name `the-function-name` with the identifier:
|
||||
|
||||
```
|
||||
(assignment_expression
|
||||
left: (identifier) @function-definition
|
||||
left: (identifier) @the-function-name
|
||||
right: (function))
|
||||
```
|
||||
|
||||
|
|
@ -501,29 +498,79 @@ And this pattern would match all method definitions, associating the name `the-m
|
|||
name: (property_identifier) @the-method-name)))
|
||||
```
|
||||
|
||||
#### Quantification Operators
|
||||
|
||||
You can match a repeating sequence of sibling nodes using the postfix `+` and `*` _repetition_ operators, which work analogously to the `+` and `*` operators [in regular expressions](https://en.wikipedia.org/wiki/Regular_expression#Basic_concepts). The `+` operator matches _one or more_ repetitions of a pattern, and the `*` operator matches _zero or more_.
|
||||
|
||||
For example, this pattern would match a sequence of one or more comments:
|
||||
|
||||
```
|
||||
(comment)+
|
||||
```
|
||||
|
||||
This pattern would match a class declaration, capturing all of the decorators if any were present:
|
||||
|
||||
```
|
||||
(class_declaration
|
||||
(decorator)* @the-decorator
|
||||
name: (identifier) @the-name)
|
||||
```
|
||||
|
||||
You can also mark a node as optional using the `?` operator. For example, this pattern would match all function calls, capturing a string argument if one was present:
|
||||
|
||||
```
|
||||
(call_expression
|
||||
function: (identifier) @the-function
|
||||
arguments: (arguments (string)? @the-string-arg))
|
||||
```
|
||||
|
||||
#### Grouping Sibling Nodes
|
||||
|
||||
You can also use parentheses for grouping a sequence of _sibling_ nodes. For example, this pattern would match a comment followed by a function declaration:
|
||||
|
||||
```
|
||||
(
|
||||
(comment)
|
||||
(function_declaration)
|
||||
)
|
||||
```
|
||||
|
||||
Any of the quantification operators mentioned above (`+`, `*`, and `?`) can also be applied to groups. For example, this pattern would match a comma-separated series of numbers:
|
||||
|
||||
```
|
||||
(
|
||||
(number)
|
||||
("," (number))*
|
||||
)
|
||||
```
|
||||
|
||||
#### Predicates
|
||||
|
||||
You can also specify other conditions that should restrict the nodes that match a given pattern. You do this by enclosing the pattern in an additional pair of parentheses, and specifying one or more *predicate* S-expressions after your main pattern. Predicate S-expressions must start with a predicate name, and contain either `@`-prefixed capture names or strings.
|
||||
You can also specify arbitrary metadata and conditions associed with a pattern by adding _predicate_ S-expressions anywhere within your pattern. Predicate S-expressions start with a _predicate name_ beginning with a `#` character. After that, they can contain an arbitrary number of `@`-prefixed capture names or strings.
|
||||
|
||||
For example, this pattern would match identifier whose names is written in `SCREAMING_SNAKE_CASE`:
|
||||
|
||||
```
|
||||
((identifier) @constant
|
||||
(match? @constant "^[A-Z][A-Z_]+"))
|
||||
(
|
||||
(identifier) @constant
|
||||
(#match? @constant "^[A-Z][A-Z_]+")
|
||||
)
|
||||
```
|
||||
|
||||
And this pattern would match key-value pairs where the `value` is an identifier with the same name as the key:
|
||||
|
||||
```
|
||||
((pair
|
||||
key: (property_identifier) @key-name
|
||||
value: (identifier) @value-name)
|
||||
(eq? @key-name @value-name))
|
||||
(
|
||||
(pair
|
||||
key: (property_identifier) @key-name
|
||||
value: (identifier) @value-name)
|
||||
(#eq? @key-name @value-name)
|
||||
)
|
||||
```
|
||||
|
||||
*Note* - Predicates are not handled directly by the Tree-sitter C library. They are just exposed in a structured form so that higher-level code can perform the filtering. However, higher-level bindings to Tree-sitter like [the Rust crate](https://github.com/tree-sitter/tree-sitter/tree/master/lib/binding_rust) or the [WebAssembly binding](https://github.com/tree-sitter/tree-sitter/tree/master/lib/binding_web) implement a few common predicates like `eq?` and `match?`.
|
||||
_Note_ - Predicates are not handled directly by the Tree-sitter C library. They are just exposed in a structured form so that higher-level code can perform the filtering. However, higher-level bindings to Tree-sitter like [the Rust crate](https://github.com/tree-sitter/tree-sitter/tree/master/lib/binding_rust) or the [WebAssembly binding](https://github.com/tree-sitter/tree-sitter/tree/master/lib/binding_web) implement a few common predicates like `#eq?` and `#match?`.
|
||||
|
||||
#### The Query API
|
||||
### The Query API
|
||||
|
||||
Create a query by specifying a string containing one or more patterns:
|
||||
|
||||
|
|
@ -583,7 +630,7 @@ This function will return `false` when there are no more matches. Otherwise, it
|
|||
|
||||
## Static Node Types
|
||||
|
||||
In languages with static typing, it can be helpful for syntax trees to provide specific type information about individual syntax nodes. Tree-sitter makes this information available via a generated file called `node-types.json`. This *node types* file provides structured data about every possible syntax node in a grammar.
|
||||
In languages with static typing, it can be helpful for syntax trees to provide specific type information about individual syntax nodes. Tree-sitter makes this information available via a generated file called `node-types.json`. This _node types_ file provides structured data about every possible syntax node in a grammar.
|
||||
|
||||
You can use this data to generate type declarations in statically-typed programming languages. For example, GitHub's [Semantic](https://github.com/github/semantic) uses these node types files to [generate Haskell data types](https://github.com/github/semantic/tree/master/semantic-ast) for every possible syntax node, which allows for code analysis algorithms to be structurally verified by the Haskell type system.
|
||||
|
||||
|
|
@ -593,9 +640,8 @@ The node types file contains an array of objects, each of which describes a part
|
|||
|
||||
Every object in this array has these two entries:
|
||||
|
||||
* `"type"` - A string that indicates which grammar rule the node represents. This corresponds to the `ts_node_type` function described [above](#syntax-nodes).
|
||||
* `"named"` - A boolean that indicates whether this kind of node corresponds to a rule name in the grammar or just a string literal. See [above](#named-vs-anonymous-nodes) for more info.
|
||||
|
||||
- `"type"` - A string that indicates which grammar rule the node represents. This corresponds to the `ts_node_type` function described [above](#syntax-nodes).
|
||||
- `"named"` - A boolean that indicates whether this kind of node corresponds to a rule name in the grammar or just a string literal. See [above](#named-vs-anonymous-nodes) for more info.
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
@ -614,16 +660,16 @@ Together, these two fields constitute a unique identifier for a node type; no tw
|
|||
|
||||
#### Internal Nodes
|
||||
|
||||
Many syntax nodes can have *children*. The node type object describes the possible children that a node can have using the following entries:
|
||||
Many syntax nodes can have _children_. The node type object describes the possible children that a node can have using the following entries:
|
||||
|
||||
* `"fields"` - An object that describes the possible [fields](#node-field-names) that the node can have. The keys of this object are field names, and the values are *child type* objects, described below.
|
||||
* `"children"` - Another *child type* object that describes all of the node's possible *named* children *without* fields.
|
||||
- `"fields"` - An object that describes the possible [fields](#node-field-names) that the node can have. The keys of this object are field names, and the values are _child type_ objects, described below.
|
||||
- `"children"` - Another _child type_ object that describes all of the node's possible _named_ children _without_ fields.
|
||||
|
||||
A *child type* object describes a set of child nodes using the following entries:
|
||||
A _child type_ object describes a set of child nodes using the following entries:
|
||||
|
||||
* `"required"` - A boolean indicating whether there is always *at least one* node in this set.
|
||||
* `"multiple"` - A boolean indicating whether there can be *multiple* nodes in this set.
|
||||
* `"types"`- An array of objects that represent the possible types of nodes in this set. Each object has two keys: `"type"` and `"named"`, whose meanings are described above.
|
||||
- `"required"` - A boolean indicating whether there is always _at least one_ node in this set.
|
||||
- `"multiple"` - A boolean indicating whether there can be _multiple_ nodes in this set.
|
||||
- `"types"`- An array of objects that represent the possible types of nodes in this set. Each object has two keys: `"type"` and `"named"`, whose meanings are described above.
|
||||
|
||||
Example with fields:
|
||||
|
||||
|
|
@ -635,31 +681,25 @@ Example with fields:
|
|||
"body": {
|
||||
"multiple": false,
|
||||
"required": true,
|
||||
"types": [
|
||||
{"type": "statement_block", "named": true}
|
||||
]
|
||||
"types": [{ "type": "statement_block", "named": true }]
|
||||
},
|
||||
"decorator": {
|
||||
"multiple": true,
|
||||
"required": false,
|
||||
"types": [
|
||||
{"type": "decorator", "named": true}
|
||||
]
|
||||
"types": [{ "type": "decorator", "named": true }]
|
||||
},
|
||||
"name": {
|
||||
"multiple": false,
|
||||
"required": true,
|
||||
"types": [
|
||||
{"type": "computed_property_name", "named": true},
|
||||
{"type": "property_identifier", "named": true},
|
||||
{ "type": "computed_property_name", "named": true },
|
||||
{ "type": "property_identifier", "named": true }
|
||||
]
|
||||
},
|
||||
"parameters": {
|
||||
"multiple": false,
|
||||
"required": true,
|
||||
"types": [
|
||||
{"type": "formal_parameters", "named": true}
|
||||
]
|
||||
"types": [{ "type": "formal_parameters", "named": true }]
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -676,8 +716,8 @@ Example with children:
|
|||
"multiple": true,
|
||||
"required": false,
|
||||
"types": [
|
||||
{"type": "_expression", "named": true},
|
||||
{"type": "spread_element", "named": true}
|
||||
{ "type": "_expression", "named": true },
|
||||
{ "type": "spread_element", "named": true }
|
||||
]
|
||||
}
|
||||
}
|
||||
|
|
@ -685,11 +725,11 @@ Example with children:
|
|||
|
||||
#### Supertype Nodes
|
||||
|
||||
In Tree-sitter grammars, there are usually certain rules that represent abstract *categories* of syntax nodes (e.g. "expression", "type", "declaration"). In the `grammar.js` file, these are often written as [hidden rules](./creating-parsers#hiding-rules) whose definition is a simple [`choice`](./creating-parsers#the-grammar-dsl) where each member is just a single symbol.
|
||||
In Tree-sitter grammars, there are usually certain rules that represent abstract _categories_ of syntax nodes (e.g. "expression", "type", "declaration"). In the `grammar.js` file, these are often written as [hidden rules](./creating-parsers#hiding-rules) whose definition is a simple [`choice`](./creating-parsers#the-grammar-dsl) where each member is just a single symbol.
|
||||
|
||||
Normally, hidden rules are not mentioned in the node types file, since they don't appear in the syntax tree. But if you add a hidden rule to the grammar's [`supertypes` list](./creating-parsers#the-grammar-dsl), then it *will* show up in the node types file, with the following special entry:
|
||||
Normally, hidden rules are not mentioned in the node types file, since they don't appear in the syntax tree. But if you add a hidden rule to the grammar's [`supertypes` list](./creating-parsers#the-grammar-dsl), then it _will_ show up in the node types file, with the following special entry:
|
||||
|
||||
* `"subtypes"` - An array of objects that specify the *types* of nodes that this 'supertype' node can wrap.
|
||||
- `"subtypes"` - An array of objects that specify the _types_ of nodes that this 'supertype' node can wrap.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -698,11 +738,11 @@ Example:
|
|||
"type": "_declaration",
|
||||
"named": true,
|
||||
"subtypes": [
|
||||
{"type": "class_declaration", "named": true},
|
||||
{"type": "function_declaration", "named": true},
|
||||
{"type": "generator_function_declaration", "named": true},
|
||||
{"type": "lexical_declaration", "named": true},
|
||||
{"type": "variable_declaration", "named": true}
|
||||
{ "type": "class_declaration", "named": true },
|
||||
{ "type": "function_declaration", "named": true },
|
||||
{ "type": "generator_function_declaration", "named": true },
|
||||
{ "type": "lexical_declaration", "named": true },
|
||||
{ "type": "variable_declaration", "named": true }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
|
@ -719,17 +759,13 @@ Example:
|
|||
"declaration": {
|
||||
"multiple": false,
|
||||
"required": false,
|
||||
"types": [
|
||||
{"type": "_declaration", "named": true}
|
||||
]
|
||||
"types": [{ "type": "_declaration", "named": true }]
|
||||
},
|
||||
"source": {
|
||||
"multiple": false,
|
||||
"required": false,
|
||||
"types": [
|
||||
{"type": "string", "named": true}
|
||||
]
|
||||
},
|
||||
"types": [{ "type": "string", "named": true }]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue