Pure refactor. Use `bench_function` instead of `bench_with_input` and
just borrow data from outside closure. This shortens the code and (I
think) makes it easier to read.
close: #7900
After #4283 changed, we don't need to inherit `ScopeFlags` from the `constructor`, `set`, `get` anymore, I think this is a logic of forgetting to remove
`just submodules` run `just update-transformer-fixtures`. Otherwise
after updating submodules, transformer tests will break. Most people
won't know that they need to run `just update-transformer-fixtures` too.
Also make `just update-transformer-fixtures` work on Windows.
``` ts
export type { a };
export { type b };
```
In the above cases, `a` and `b` are both type-only references. Before, we handled them in `visit_export_named_declaration` and `visit_export_specifier`, but it doesn't look intuitive due to we need to determine
if `ExportNamedSpecifier` is a type-only in `visit_export_specifier ` by checking if `current_reference_flags` is a type, and also needs to set it back before exit node.
This PR moves determining reference flags from `visit_export_specifier` to `visit_export_named_declaration` so that we don't need to check `current_reference_flags` and set it back because here we can always know the
if `ExportSpecifierNamed` is type-only by `ExportNamedDeclaration::export_kind::is_type`.
For this case, we set `current_reference_flags` to `ReferenceFlags::Type` for `TSInterfaceHeritage`, but never unset it, which causes resolving `fowardRef` identifier reuse `current_reference_flags` of `TSInterfaceHeritage`.
```ts
import { forwardRef } from "react";
export interface MenuTriggerProps extends Object {}
export const MenuTrigger = forwardRef();
```
In this PR, reset the `current_reference_flags` when resolved, so that we don't need to reset it in individual visit functions. This is a reasonable change because the `current_reference_flags` only applies to the next encountered identifier.
Do not create temp var for computed key which is `TemplateLiteral` with no expressions. Evaluating such a template literal cannot have side effects.
```js
class C {
[`foo`] = 1;
}
```
But this *can* have side effects:
```js
class C {
[`foo${bar}`] = 1;
}
```
Previously where a class method had a computed key which does not require a temp var (e.g. `const methodName = 'x'; class C { [methodName]() {} }`), the `PropertyKey` was consumed and replaced with a newly-generated one which was identical to the original. Skip this pointless work.
Split out methods from `class.rs` into separate files.
Note: `static_block.rs` is currently very small, but it will get bigger - a new visitor is required here to rename references to class name and `this`.
Adds `top_level` option which is similar to [terser's `toplevel`
option](https://terser.org/docs/cli-usage/#cli-mangle-options).
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Pure refactor. Rename file for clarity that it relates to transform of private fields (`this.#prop`) and not private property declarations (`#x = 123`).
Small optimization.
Replace string slice + `starts_with` (at least 3 x bounds checks + 2 x UTF8 character boundary checks) with a single byte read (1 x bounds check).
Static property initializers need to be modified in various ways. One is to change the parent scope of the first level of scopes in the initializer to the new parent scope.
Lots of nodes which have scopes cannot be the first level. e.g. an `IfStatement` cannot because it would have to be inside a function, and that function would be the first-level scope. The `IfStatement` must be a nested scope, so we know we won't need to update its parent.
Skip checking if we need to update parent scope for all these nodes.
Add a fast path for inserting instance property initializers into constructor, when no existing constructor or constructor has no bindings. This should be reasonably common.
The `Scope flags mismatch` errors are due to #7900.
#7872 implements renaming symbols in constructor which shadow references in instance property initializers. But we don't need to rename where the reference in initializer references a symbol which is bound within the initializer itself.
Input:
```js
class C {
double = n => n * 2;
constructor(n) {
console.log(n);
}
}
```
Output:
```js
class C {
constructor(n) { // <-- not renamed
this.double = n => n * 2; // <-- moved into constructor
console.log(n); // <-- not renamed
}
}
```
This produces better output, and avoids a traversal of constructor's AST renaming symbols.
Instance property initializers are moved into constructor. If symbols they reference are shadowed within constructor, rename those symbols.
Input:
```js
class C {
prop = foo();
constructor(foo) {
console.log(foo);
}
}
```
Output:
```js
class C {
constructor(_foo) { // <-- renamed
this.prop = foo(); // <-- moved into constructor
console.log(_foo); // <-- renamed
}
}
```
based on #7890
tried graphite, but I do not have write access to this repo.
Do not know how to create Branches on a Fork and the PRs on the Forked
Project.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Pure refactor. Re-order imports for clarity:
1. `std`
2. External crates
3. `oxc_*` crates
4. Current crate `use crate::...`
5. Super `use super::...`
6. Local modules
This order is from "furthest away" to "closest". This makes it clearer to see what is coming from where.
`cargo +nightly fmt` (#7877) did a lot of the work, but unfortunately `rustfmt` does not have an option to (a) put workspace crates in a separate block from external crates and (b) move `mod` statements to after `use` statements.
`oxc_semantic` had a bit of a mess of modules importing and re-exporting symbols from `oxc_syntax` all over the place. I assume this is a leftover from when our crates were structured differently.
Make this consistent by always importing `oxc_syntax`'s symbols from `oxc_syntax`, and only re-export them from the crate root.
`oxc_semantic` already re-exports `ScopeId`, `ScopeFlags`, `SymbolId` and `SymbolFlags` from `oxc_syntax`. It seems inconsistent that it doesn't also re-export `ReferenceId`, `ReferenceFlags`, `NodeId` and `NodeFlags` too. Do that.
closes#7849
This is essentially because `get_element_type` does not support
recognizing tag names like `<a.b />`. I'm unsure whether we should
support it.
Follow-on after #7831. Break up `transform_call_expression_for_super_member_expr` into multiple functions, to make `transform_call_expression_for_super_member_expr` as small as possible, to encourage inlining it.
