yarp 0.10.0 → 0.11.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/CHANGELOG.md +25 -1
- data/CONTRIBUTING.md +7 -0
- data/config.yml +154 -43
- data/docs/configuration.md +0 -1
- data/docs/mapping.md +91 -91
- data/docs/serialization.md +23 -20
- data/ext/yarp/api_node.c +1074 -391
- data/ext/yarp/extension.c +1 -1
- data/ext/yarp/extension.h +2 -2
- data/include/yarp/ast.h +501 -301
- data/include/yarp/diagnostic.h +198 -1
- data/include/yarp/node.h +0 -4
- data/include/yarp/util/yp_char.h +1 -1
- data/include/yarp/util/yp_constant_pool.h +11 -4
- data/include/yarp/version.h +2 -2
- data/lib/yarp/desugar_visitor.rb +19 -19
- data/lib/yarp/mutation_visitor.rb +22 -12
- data/lib/yarp/node.rb +2883 -293
- data/lib/yarp/parse_result/comments.rb +172 -0
- data/lib/yarp/parse_result/newlines.rb +60 -0
- data/lib/yarp/pattern.rb +239 -0
- data/lib/yarp/serialize.rb +152 -129
- data/lib/yarp.rb +104 -44
- data/src/diagnostic.c +254 -2
- data/src/node.c +901 -868
- data/src/prettyprint.c +380 -186
- data/src/serialize.c +325 -170
- data/src/unescape.c +20 -20
- data/src/util/yp_char.c +2 -7
- data/src/util/yp_constant_pool.c +41 -8
- data/src/util/yp_newline_list.c +5 -1
- data/src/util/yp_string_list.c +4 -1
- data/src/yarp.c +946 -818
- data/yarp.gemspec +4 -1
- metadata +6 -3
data/docs/serialization.md
CHANGED
|
@@ -81,32 +81,35 @@ Each node is structured like the following table:
|
|
|
81
81
|
| `1` | node type |
|
|
82
82
|
| location | node location |
|
|
83
83
|
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
* `node` - A
|
|
89
|
-
* `
|
|
90
|
-
* `node[]` - A child node that is an array of nodes. This is structured as a variable-length integer length, followed by the child nodes themselves.
|
|
91
|
-
* `string` - A child node that is a string. For example, this is used as the name of the method in a call node, since it cannot directly reference the source string (as in `@-` or `foo=`). This is structured as a variable-length integer byte length, followed by the string itself (_without_ a trailing null byte).
|
|
84
|
+
Every field on the node is then appended to the serialized string. The fields can be determined by referencing `config.yml`. Depending on the type of field, it could take a couple of different forms, described below:
|
|
85
|
+
|
|
86
|
+
* `node` - A field that is a node. This is structured just as like parent node.
|
|
87
|
+
* `node?` - A field that is a node that is optionally present. If the node is not present, then a single `0` byte will be written in its place. If it is present, then it will be structured just as like parent node.
|
|
88
|
+
* `node[]` - A field that is an array of nodes. This is structured as a variable-length integer length, followed by the child nodes themselves.
|
|
89
|
+
* `string` - A field that is a string. For example, this is used as the name of the method in a call node, since it cannot directly reference the source string (as in `@-` or `foo=`). This is structured as a variable-length integer byte length, followed by the string itself (_without_ a trailing null byte).
|
|
92
90
|
* `constant` - A variable-length integer that represents an index in the constant pool.
|
|
93
|
-
* `constant
|
|
94
|
-
* `location` - A
|
|
95
|
-
* `location?` - A
|
|
96
|
-
* `
|
|
97
|
-
|
|
91
|
+
* `constant?` - An optional variable-length integer that represents an index in the constant pool. If it's not present, then a single `0` byte will be written in its place.
|
|
92
|
+
* `location` - A field that is a location. This is structured as a variable-length integer start followed by a variable-length integer length.
|
|
93
|
+
* `location?` - A field that is a location that is optionally present. If the location is not present, then a single `0` byte will be written in its place. If it is present, then it will be structured just like the `location` child node.
|
|
94
|
+
* `uint32` - A field that is a 32-bit unsigned integer. This is structured as a variable-length integer.
|
|
95
|
+
|
|
96
|
+
After the syntax tree, the content pool is serialized. This is a list of constants that were referenced from within the tree. The content pool begins at the offset specified in the header. Constants can be either "owned" (in which case their contents are embedded in the serialization) or "shared" (in which case their contents represent a slice of the source string). The most significant bit of the constant indicates whether it is owned or shared.
|
|
97
|
+
|
|
98
|
+
In the case that it is owned, the constant is structured as follows:
|
|
99
|
+
|
|
100
|
+
| # bytes | field |
|
|
101
|
+
| --- | --- |
|
|
102
|
+
| `4` | the byte offset in the serialization for the contents of the constant |
|
|
103
|
+
| `4` | the byte length in the serialization |
|
|
98
104
|
|
|
99
|
-
|
|
100
|
-
This is a list of constants that were referenced from within the tree.
|
|
101
|
-
The content pool begins at the offset specified in the header.
|
|
102
|
-
Each constant is structured as:
|
|
105
|
+
Note that you will need to mask off the most significant bit for the byte offset in the serialization. In the case that it is shared, the constant is structured as follows:
|
|
103
106
|
|
|
104
107
|
| # bytes | field |
|
|
105
108
|
| --- | --- |
|
|
106
|
-
| `4` | the byte offset in the source |
|
|
107
|
-
| `4` | the byte length in the source |
|
|
109
|
+
| `4` | the byte offset in the source string for the contents of the constant |
|
|
110
|
+
| `4` | the byte length in the source string |
|
|
108
111
|
|
|
109
|
-
At the end of the serialization, the buffer is null terminated.
|
|
112
|
+
After the constant pool, the contents of the owned constants are serialized. This is just a sequence of bytes that represent the contents of the constants. At the end of the serialization, the buffer is null terminated.
|
|
110
113
|
|
|
111
114
|
## APIs
|
|
112
115
|
|