The scope can be moved or deleted, we need to check whether the scope id is the same as the container's scope id, if not, we need to move the `this_var` to the target scope id.
Part of https://github.com/oxc-project/oxc/pull/7074
In async-to-generator and async-generator-functions plugins, we may need to transform the async arrow function to a regular generator function, now we can reuse the ability of the ArrowFunction plugin by enabling `ArrowFunctionConverter`.
I will fix semantic errors in the follow-up PR
Part of #7074
We need to handle this before the `arrow_function` plugin inserts `_this = this` because, in the `async-to-generator` plugin, we will move the body to an inner generator function. However, we don't want `_this = this` moved to the inner generator function as well. So as long as we move first, and then insert, we can fix this problem.
The new semantic error is related to another tricky problem, I will fix it in another PR
Passed 15/19 tests. The remaining 4 failed tests related to `this` expression, the problem same as I mentioned in #6658. I will fix them in follow-up PRs.
closes#6865
TypeScript plugin changes import / export statements so it needs to be turned off for non-typescript files. This should also give a little performance boost for non-typescript files.
In this PR, most of the async functions have transformed correctly. But the async arrow functions don't fully transform correctly yet, it is related to we need to transform the arrow function to the generator function. For example:
Input:
```js
function declaration() {
const asy = async () => {
console.log(this.name)
}
}
```
Output:
```js
function declaration() {
const asy = babelHelpers.asyncToGenerator(function* () {
console.log(this.name);
});
}
```
Expected Output:
```js
function declaration() {
var _this = this;
const asy = /*#__PURE__*/function () {
var _ref = babelHelpers.asyncToGenerator(function* () {
console.log(_this.name);
});
return function asy() {
return _ref.apply(this, arguments);
};
}();
}
```
From the expected output, we haven't handled `this` correctly, which means even if the `arrow-function` plugin doesn't enable, we still need to handle this correctly as the `arrow-function` plugin does, and further question if `arrow-function` plugin is enabled, how to avoid these making conflict?
I thought we may move out the implementation of `arrow-function` and as a common helper, this way every plugin can handle this well
Our convention is that AST type fields are ordered in order they appear in source. Move `type_parameters` fields in TS function declaration types to before `this_param` and formal parameters.
Make naming of temp vars follow Babel. It wasn't apparent that our version of this transform was behaving differently from Babel because the Babel plugin has very few tests. The added tests replicate Babel's output.
Fix exponentiation operator transform to bail out early if a private class property.
We can't transform this:
```js
class C {
#p;
method() {
this.#p **= 2;
}
}
```
But we should at least leave it alone. Previously `get_obj_ref` called `ast.move_expression(expr)` on the member expression's object before bailing out, so example above was transformed to:
```js
class C {
#p;
method() {
null.#p **= 2; // <-- `null`
}
}
```
This PR makes it spot this case early and bail out *before* calling `ast.move_expression(expr)`.
Closes#5020.
`TraverseCtx::generate_uid` and associated methods return a `BoundIdentifier`, containing both symbol ID and name. This reduces boilerplate code for the caller and avoids and unnecessary lookup to get the name.
Also add a couple of helper methods to `BoundIdentifier` to reduce boilerplate further.
Move post-transform checker into a `tasks` crate. It doesn't feel like it belongs in `oxc_semantic`. It also feels like too heavy a lump of code to put in `tasks/common`.
First step towards #5049.
Various transforms need to add a `var` statement at top of enclosing statement block.
e.g.:
```js
// Input
a ??= b;
```
```js
// Output
var _a;
(_a = a) !== null && _a !== void 0 ? _a : (a = b);
```
Each of these transforms previously maintained it's own stack and added `var` statements individually.
Share this functionality in a "common" utility transform which maintains a single stack to serve them all.
Fix JSX source transform when run alone without main JSX transform.
The added test case is same as one of Babel's exec test cases, but the exec test fails due to `transformAsync` not being present.
### Difference
In `enter_expression`: Recursive transform JSX
In `exit_expression`: Deep first transform
After the change, `transform_jsx` still has a lot of room for improvement.
Currently whether conformance fixture files have trailing line breaks is inconsistent - some have them, some don't. Make all of them have a trailing line break.
Rename transform conformance RegExp test fixtures folder from "esbuild-tests" to "regexp", to reflect that not all these tests are copied from ESBuild.
related: #4754
The implementation port from [esbuild](332727499e/internal/js_parser/js_parser.go (L12820-L12840)). And cover all babel's regexp plugins
---
## The following description was generated by `Graphite` 😋
### TL;DR
Added support for transforming various RegExp features to ensure compatibility with older JavaScript environments.
### What changed?
- Implemented a new `RegExp` transformer to handle unsupported RegExp literal features
- Added options to control different RegExp transformations (e.g., sticky flag, unicode flag, dot-all flag, etc.)
- Updated the transformer to convert unsupported RegExp literals into `new RegExp()` constructor calls
- Added test cases for different RegExp transformations
- Integrated the new RegExp transformer into the existing transformation pipeline
### How to test?
1. Run the existing test suite to ensure no regressions
2. Execute the new RegExp-specific tests in the `tasks/transform_conformance/tests/esbuild-tests/test/fixtures/regexp/` directory
3. Try transforming code with various RegExp features using different target environments to verify correct transformations
Preparation for upstack PRs. Graphical reporter diagnostics look exactly the same. This does, however, change `to_string()` to only show diagnostic messages, and not error codes + messages.
