For the test case, Closure Compiler doesn't handle this at all in the REPL! If it's necessary, I will turn it back.
This PR uses builtin `and_then` and `map` method, which is better instead of a lot of `if let Some`.
close#5530
This PR adds support for handling recursive JSX components, allowing
detect functions like the one below:
```javascript
function ListItem({ depth }) {
return <ListItem depth={depth} />
}
```
Some logic is duplicated with the non-JSX case. But the refactor will be
complicated and affects over-all, so we can make it in another PR.
cc: @DonIsaac @camc314
---------
Co-authored-by: Cam McHenry <camchenry@users.noreply.github.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
for convenience, I've added a new function called `ancestor_kinds` which loops overall `ancestors` and gets their `AstKind`. this is a common pattern in a couple of places. I also did some somewhat related refactoring to remove places where we were manually calling `AstNode::kind` instead of using `ancestor_kinds` or calling `parent_kind`.
for consistency with the `ancestor_ids` function, this changes it to use the same terminology but make it clear it actually returns the node, not just the ID.
this is pure refactor, no functional changes here.
After transformation, super expressions have moved to unexpected places. This PR replaces super expression to call expression, and then inserts the super methods to the top of the method body.
For example:
Before:
```js
class G {
async method() {
super.foo()
}
}
```
After:
```js
class G {
method() {
var _superprop_getFoo = () => super.foo,
_this = this;
return _asyncToGenerator(function* () {
_superprop_getFoo().call(_this);
})();
}
}```
Support for inferring function name from ObjectPropertyValue's key
For example:
```js
({ foo: async function() {} })
```
After this, we will able to infer `foo` for the object method
I don't think we need two separate channels for output. This replaces
the 2 existing channels with a single channel that allows configuring
the log level.
Ref #7136
Currently `oxc-vscode.trace.server` needs to be used to enable trace
logging for the language server. This fixes it so that
`oxc.trace.server` can be used. I can't find any guidance on what should
be used for the language client id. The VS Code ESLint plugin uses
"ESLint", so I think this change should be fine.
Ref https://github.com/oxc-project/oxc/issues/7136.
Adds some new estree macro directives:
- `#[estree(via = foo::Foo)`: Uses From to convert this struct to foo::Foo before serialization
- `#[estree(add_ts = "foo: string")]`: Adds additional fields to the typescript definitions
Used these to make all different literals estree-compatible.
Follow-on after stack up to #7148.
Split `is_inside_async_generator_function` into 2 functions `yield_is_inside_async_generator_function` and `async_is_inside_async_generator_function`.
There are a couple of differences between `yield` and `await`, which we can leverage to make both these functions simpler:
* `yield` cannot appear at top level (there's no such thing as "top level yield").
* `yield` cannot appear in an arrow function (there's no such thing as a "generator arrow function").
In addition:
* Because each function now handles a specific case, no need to check if function containing `async` is an async function. It must be. Ditto for `yield`.
* Remove the `if ctx.current_scope_flags().is_top()` check. Probably this check costs more than it saves because top level `await` is far less common than `await` within async functions. So this check was optimizing for an uncommon case, at a cost to the common case.
* Add more comments to explain the logic.
This is all quite small optimizations, but I was having difficulty understanding the logic, and found that splitting it up made it clearer (at least for me).
Follow-on after stack up to #7148.
Small optimization. `LabelIdentifier` is `Clone` so we can use `Clone::clone` to clone it, instead of `CloneIn::clone_in`.
The difference is that `clone_in` makes a 2nd copy of the `Atom`'s string in the arena, whereas `clone` creates a new `Atom` referencing the same string. This is an unfortunate shortcoming of `CloneIn` (https://github.com/oxc-project/backlog/issues/96), but the more we can avoid `CloneIn`, the better.
Follow-on after stack up to #7148.
Small optimization. `ArrowFunctionExpression` is 56 bytes, whereas `ArenaBox<ArrowFunctionExpression>` is 8 bytes. So it's preferable to pass the `ArenaBox<ArrowFunctionExpression>` to `transform_arrow_function_expression` and call `unbox` on it there instead of unboxing *before* passing to the function.
Follow-on after stack up to #7148. Remove 2 x `#[allow(clippy::unused_self)]` attrs where that lint isn't triggered because the functions do use their `&self` param.
