Follow up from
https://github.com/oxc-project/oxc/pull/8543#discussion_r1918592423
> I agree. https://github.com/oxc-project/backlog/issues/155
> Originally we were considering some form of interning and
reference-counting, so we didn't make it Copy to leave the door open for
that. But now all strings are stored in the arena anyway, so even if we
did decide to intern strings, reference-counting would be irrelevant -
our bump allocator doesn't allow freeing individual allocations anyway.
Most of the changes are done automatically by `just fix` (`cargo clippy
--fix` && `cargo fmt --all`). See the commit list for the manual edits.
`Span` consists of 2 x `u32` (8 bytes total). Align `Span` on 8 bytes on 64-bit platforms. This means that, on 64-bit platforms, `Span` can be treated as equivalent to a `u64` and stored in a single register (instead of requiring 2).
A side-effect is that all AST structs also become aligned on 8. This will be a useful property later on as we can remove alignment calculations from `Allocator::alloc` (since everything now has same alignment).
`BooleanLiteral` (and `BoundaryAssertion`, `CharacterClassEscape` and `IndexedReference` from `oxc_regular_expression` crate) increase from 12 bytes to 16 bytes due to the higher alignment. But this makes no practical difference as they'd almost always end up with padding around them in arena anyway, as they'll be surrounded by 8-aligned types.
The lexer benchmarks had a problem. The lexer alone cannot make sense of regexp literals, template literals, or JSX text elements - it needs the parser "driving" it.
So lexer was producing plenty of errors on some benchmarks. This is unrealistic - when driven by the parser, the lexer produces no errors. Generating diagnostics is relatively expensive, so this was skewing the benchmarks somewhat.
Solve this by cleaning up the input source text to replace these syntaxes with string literals prior to running the benchmarks.
Unfortunately lexer benchmarks don't exercise the code paths for these syntaxes, but there isn't much we can do about that. We can judge by the parser benchmarks, which are the more important ones anyway.
fixes: #8437
In semantic builder make sure `Program` reference has a lifetime of the
Arena.
---------
Co-authored-by: overlookmotel <theoverlookmotel@gmail.com>
Add `AstKind::ty` method to get `AstType` from an `AstKind`.
Works by setting the enum discriminants of `AstKind` and `AstType` to be the same, so one can be converted to the other at zero cost.
The new implementation port from [esbuild](df815ac27b/internal/js_parser/js_parser_lower.go (L355-L467)), before from `Babel`.
Babel's transform implementation for the async method is incorrect because the async method should return a rejecting promise when it throws an error. Everything is good if the errors are thrown in the async method body, but the following case will throw an error in the parameters which causes the whole program crushed not a rejecting promise. So we should move the parameters to the inner generator function when the parameters could throw an error.
Input:
```js
class Cls {
// ReferenceError: Cannot access 'b' before initialization
async method(a = b, b = 0) {}
}
```
Before output
```js
class Cls {
method(a = b, b = 0) {
return babelHelpers.asyncToGenerator(function* () {})();
}
}
```
After output:
```js
class Cls {
method() {
// ReferenceError: Cannot access 'b' before initialization
return babelHelpers.asyncToGenerator(function* (a = b, b = 0) {}).apply(this, arguments);
}
}
```
No override tests because Babel doesn't cover this case.
Update babel submodule for conformance tests to latest HEAD.
The test fixtures include a new one for a bug fix which @branchseer
intends to also apply to Oxc - https://github.com/babel/babel/pull/17050
(see #8342).
Follow-on after #8482.
Fix an edge case in arrow functions transform when inserting `_this = this` after `super()`. It is possible (though bizarre) for `super()` to contain another `super()` call. This will throw an error when evaluating the outer `super()`, but it can still be observable in some cases.
```js
let f;
class S {}
class C extends S {
constructor(x) {
super(super(), this.x = x, f = async () => this);
}
}
try { new C(123) } catch {}
const c = await f();
assert(c.x === 123);
```
So, before bailing out from searching for more `super()`s in class constructor, visit the `super()` call's arguments.
Some of Babel's exec tests contain a return statement at top level, in order to return a Promise.
e.g. ad572fd1a1/packages/babel-plugin-transform-private-methods/test/fixtures/private-method-loose/async/exec.js
These test files could not be parsed due to illegal position of `return`, and the tests were silently excluded.
This PR:
1. Includes those tests by passing `allow_return_outside_function: true` option to parser for exec tests.
2. Includes a "transform error" message in snapshot for any exec tests which produce errors in parser/transformer.
Found a bunch of failed tests related to we don't use
`classPrivateSetter` and `classPrivateGetter` to transform private
getter and private setter. The simplest way is to add alternative helper
functions for these two. The reason we don't use I have explained in
#8132
```shell
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-add.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «3») to be true
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-bitand.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «0») to be true
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-bitor.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «15») to be true
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-bitxor.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «257») to be true
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-div.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «0.5») to be true
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-exp.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «1000») to be true
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-lshift.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «96») to be true
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-mod.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «1») to be true
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-mult.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «6») to be true
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-rshift.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «3») to be true
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-srshift.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «3») to be true
tasks/coverage/test262/test/language/expressions/compound-assignment/left-hand-side-private-reference-accessor-property-sub.js
transform error: Test262Error: The expression should evaluate to the result Expected SameValue(«undefined», «1») to be true
```
I did a few things in this PR,
1. Remove `names` which store the declarations name used for checking re-declaration. (We can use SymbolTable to do it now.)
2. Correct semantic data for namespace transform
3. Simplify code
close: #8385
This PR is to solve the missing `super` transform in the async arrow function, and `_this = this` inserts to an incorrect place. These problems are all about the async arrow function, which is a part of the init of class property. Learn more at #8387.
The output matches Babel's output except for static prop as Babel transforms incorrectly.
Compresses `new Int8Array(0)` into `new Int8Array()`. (then will be compress into `new Int8Array`).
Partial quote from the [spec](https://tc39.es/ecma262/multipage/indexed-collections.html#sec-typedarray):
> 5. If numberOfArgs = 0, then
> a. Return ? AllocateTypedArray(constructorName, NewTarget, proto, 0).
> 6. Else,
> c. Else,
> ii. Let elementLength be ? ToIndex(firstArgument).
> iii. Return ? AllocateTypedArray(constructorName, NewTarget, proto, elementLength).
