Get desktop application:
View/edit binary Protocol Buffers messages
Top-level AST definition.
The shortened language name. E.g. "js"
Babel AST in the form of JSON string.
Used in:
The actual string.
Whether string literals have been base64-encoded.
Used in:
Used in:
Used in: , ,
Options for the Babel code generator.
Used in:
Whether comments are kept in the generated source.
Whether to minify the generated source.
Whether to generate source maps.
Used in:
Should comments be included in output?
Whether we should base64-decode string literals.
Whether to minify the generated source.
Whether to generate source maps.
Used in:
Babel throws exceptions if the provided AST is invalid.
Options for the Babel parser.
Used in: ,
Enables error recovery in the parser. Note that error recovery is only available since babel_parser 7.7.0, so only v8_babel supports it, not sandboxed_nodejs_babel. https://babeljs.io/blog/2019/11/05/7.7.0
Replaces invalid surrogate pairs with double question mark symbol (\UFFFD). JavaScript strings are represented as UTF-16. Surrogate pairs are characters represented by two 16-bit numbers. Each surrogate pair must start with a high surrogate (in [U+D800, U+DBFF]), and end with a low surrogate (in [U+DC00 to U+DFFF]). A single surrogate, or a pair that starts with a low surrogate and ends with a high surrogate is considered invalid. If the UTF-16 character sequence is invalid, then nlohmann::json fails to parse the JSON string. This flag enables the feature that converts any surrogate character that is not part of a valid surrogate pair into '�' (\UFFFD). Example: "abc\UD834\UDF06" -> "abc𝌆" (valid surrogate pair) "abc\UD834" -> "abc�" (lone surrogate) "abc\UDF06\UD834" -> "abc��" (invalid surrogate pair) See b/235090893 for context. replace_invalid_surrogate_pairs == false: ``` Node { type: 'StringLiteral', extra: { rawValue: '\udf06\ud834', raw: '"\\udf06\\ud834"' }, value: '\udf06\ud834' } ``` replace_invalid_surrogate_pairs == true: ``` Node { type: 'StringLiteral', extra: { rawValue: '\ufffd', raw: '"\\udf06\\ud834"' }, value: '\ufffd' } ```
Whether string literals will be base64-encoded in the AST. base64_encode_string_literals == false: ``` Node { type: 'StringLiteral', extra: { rawValue: 'A', raw: '"\u0041"' }, value: 'A' } ``` base64_encode_string_literals == true: ``` Node { type: 'StringLiteral', extra: { rawValue: 'YQ==', raw: '"\u0041"' }, value: 'YQ==' } ```
Whether to add scope information in the AST. If true: - A separate Scopes proto will be returned - Each AST node will have an additional scopeUid field, specifying which scope it belongs to
The mode in which source code should be parsed. "unspecified" defaults to "script". "unambiguous" will make @babel/parser attempt to guess, based on the presence of ES6 import or export statements. Files with ES6 imports and exports are considered "module" and are otherwise "script".
Used in:
Should the parser work in strict mode (i.e. throw more errors). According to Babel's comment, if strictMode is undefined, then it depends on whether sourceType is 'module'. However, the source code has a bug such that even if strictMode is true, the parser still depends on sourceType. Implementation: +------------------------+--------------------------+ | | strictMode | | +-----------+------+-------+ | | undefined | true | false | +---------------+--------+-----------+------+-------+ | source type | module | ✓ | | | (specified +--------+------------------+ ✗ | | or inferred) | script | ✗ | | +---------------+--------+------------------+-------+ Specification: +------------------------+--------------------------+ | | strictMode | | +-----------+------+-------+ | | undefined | true | false | +---------------+--------+-----------+------+-------+ | source type | module | ✓ | | | | (specified +--------+-----------+ ✓ | ✗ | | or inferred) | script | ✗ | | | +---------------+--------+-----------+------+-------+
Used in:
Only contains the errors (if any) in the response. The AST is returned separately.
Used in:
Some errors are recoverable and/or are not severe enough to stop parsing. Currently Babel always throws an exception when parsing fails, so we can have at most one error.
Used in:
Used in: ,
Used in: , ,
(message has no fields)
Used in: , ,
(message has no fields)
Used in:
Used in:
Definition of a field in an AST node.
Used in:
Name of the field. Must be camelCase.
The optionalness of a field - whether it might be null or undefined.
The type of the field.
The field kind. E.g. LVAL.
Whether the field should be ignored in the IR op. For example, we might want to ignore the source location fields, since MLIR has builtin support for source location. In the AST <-> IR conversion, we need to supply some manually-written code to convert between source location fields and MLIR's source location attributes.
Whether the field should be enclosed in a region. For example, if the field is a statement, we should create a nested region and enclose the field in it. Detail: Normally, an argument of an IR op is logically executed before the op itself. For example, consider the following AST: ``` BinaryExpression { operator: "+" left: Identifier { "a" } right: Identifier { "b" } } ``` We can transform it into the following IR: ``` %left = jsir.identifier {"a"} %right = jsir.identifier {"b"} %bin_expr = jsir.binary_expression (%left, %right) ``` We can see that the IR is, in a sense, a post-order traversal of the AST. However, if an AST node has a statement field, we cannot model it in the IR this way. For example, consider the following AST: ``` IfStatement { test: Identifier { "a" } body: SomeSortOfStatement {} } ``` If we are to use the same approach, we would transform it into the following IR: ``` %test = jsir.identifier {"a"} %body = jsir.some_sort_of_statement jsir.if_statement (%test, %body) ``` This is problematic, because: 1. The semantics of the if statement is that `body` might not be executed. However, in this IR it appears that body is always executed. 2. jsir.some_sort_of_statement shouldn't have a return value. However, in this IR it must have one, just for the if_statement to reference the op. Therefore, we need to put body **inside** of the if statement, like this: ``` %test = jsir.identifier {"a"} jsir.if_statement (%test) { jsir.some_sort_of_statement } ``` Therefore, we define `enclose_in_region` to specify that this AST field, when converted to an IR op, should be further enclosed in a region.
========= FieldKind ========= Each field in an AST node has a "kind". This is because different kinds of AST nodes lead to different forms of IR ops. Example: For the assignment expression "x = y", lhs and rhs have the same AST node type: Identifier. AST: ``` AssignmentExpression { lhs: Identifier {"x"} rhs: Identifier {"y"} } ``` However, lhs is an lvalue, but rhs is an rvalue. Therefore, they lower to different IR ops: ``` %lhs = identifier_ref {"x"} %rhs = identifier {"y"} assignment_expression (%lhs, %rhs) ``` We can see that "x" lowers to an "identifier_ref" op, but "y" lowers to an "identifier" op. In order to support this, we need to: - Specify that Assignment::lhs has an "LVAL" kind. - Specify that Assignment::rhs has an "RVAL" kind. - Specify that the Identifier node type can be both LVAL and RVAL.
Used in: , ,
This field is an attribute (has builtin type).
This field is an rvalue expression. If the expression type has an LVAL kind, we need to create an additional "load" op.
This field is an lvalue expression. The expression type must have an LVAL kind.
This field is a statement.
Used in: , ,
(message has no fields)
Used in:
Used in:
Added by JsAstTransformConfig.ExtractPrelude
Used in:
Used in:
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
Used in:
(message has no fields)
Used in:
The indices of the top-level statements to extract.
Used in:
source <=> ast string
ast string <=> ast
ast <=> hir
Used in:
(message has no fields)
Used in:
Analysis
Transform
Used in:
Used in:
========================================================================= JSIR Dataflow Analyses ========================================================================= The result of a JSIR dataflow analysis contains lattice elements attached to MLIR operations and MLIR values. As a result, it can't be returned in a standalone proto. Here we will just return a string for debugging purposes.
Used in:
(message has no fields)
Used in: , ,
The scope uid of the scope where the prelude is extracted from. * If the prelude is extracted from the AST, this is the global scope uid of the original AST. * If the prelude is not extracted from the AST, this field is not set. Details: When we use the ExtractPrelude pass to remove the prelude from the AST, the corresponding `BabelScopes` still reflects the original AST, which means the prelude symbols are still in the global scope. Here we store the uid of the global scope in the original AST, so that the dynamic constant propagation analysis can correctly find the prelude symbols. If the prelude is not extracted from the AST, i.e. the prelude is provided by the user, then the prelude symbols are not in the global scope of the AST to be analyzed. In this case, this field is not set.
Used in:
Used in: ,
Used in:
A debug print of the const bindings.
Used in:
Used in:
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
MLIR traits.
Used in:
Pure
IsolatedFromAbove
Definition of an AST node type.
Used in:
Name of the node. Must be PascalCase. E.g. "BinaryExpression".
Type kind string. In the JavaScript object version of the AST, a special "type" string represents the kind of the node. interface BinaryExpression <: Expression { type: "BinaryExpression"; <============ This field. operator: BinaryOperator; left: Expression | PrivateName; right: Expression; } The "type" string only has a concrete value in leaf types. interface Expression <: Node { } <======= No "type" value defined. The existence of a concrete "type" value suggests that this is a leaf type.
Parent nodes to inherit from.
Fields defined by this node. Not including fields in parents.
If true, automatically generate the corresponding op. If false, the op is expected to be manually written.
Supported kinds. Each kind leads to a different IR op.
Whether this op has control flow. If so, we will define a high-level IR op, and a low-level IR op.
[Optional] Custom MLIR op name. By default, each AST node corresponds to an equivalent op or interface: - JsNumericLiteral <=> JsirNumericLiteralOp - JsExpression <=> JsirExpressionOpInterface If a custom op name is specified, then the corresponding MLIR op will not be generated, and its ancestors will not have corresponding interfaces. - JsNumericLiteral <=> mlir::arith::ConstantOp - JsExpression <=> mlir::Value
Whether this node has a fold operation
Additional MLIR traits to add to the op definition.
Used in:
This is an unfortunate Babel-specific detail. Since Babel's AST is a JSON object, maybe_null and maybe_undefined are different cases. - "field: string | null" This means the field must exist, but could be null. Example: The specification for "AwaitExpression" is this: ``` interface AwaitExpression <: Expression { type: "AwaitExpression"; argument: Expression | null; } ``` In the above example, "argument" is maybe_null, which means that in the JSON object, the entry must exist, but the value can be null: ``` { "type": "AwaitExpression", "argument": null // <---- value is null. } ``` - "field?: string" This means the field might not exist, but if it does, it must be non-null. Example: The specification for "CatchClause" is this: ``` interface CatchClause <: Node { type: "CatchClause"; param?: Pattern; body: BlockStatement; } ``` In the above example, "param" is maybe_undefined, which means that in the JSON object, the entry might not exist at all: ``` { "type": "CatchClause", // <---- "param" doesn't exist. "body": { ... } } ``` However, it appears that in Babel's AST, there is no field that is both maybe_null and maybe_undefined (in other words, there is no such thing as "field?: string | null"). Therefore, both cases are represented as "std::optional<std::string>".
Used in:
No semantic meaning. go/protodosdonts#do-include-an-unspecified-value-in-an-enum
Field must exist and be non-null.
Field must exist, but might be null.
Field might not exist, but when it exists, it must be non-null.
Used in:
Used in:
Used in: , ,
(message has no fields)
Used in:
Definition of a tagged union node type. SWC likes to use enum types to model inheritance. This union type simplifies the AST definitions by allowing us to mimic this model and implicitly add the associated union type as a parent to all the enum members.
Used in:
Name of the union node. Must be PascalCase. E.g. "BinaryExpression".
Parent nodes to inherit from.
Types which are members of this union.
If true, automatically generate the corresponding op. If false, the op is expected to be manually written.
Supported kinds. Each kind leads to a different IR op.
Used in: ,