one/two wierd tests are not covered
> This is also an object option whose value is an array. This option
allows you to specify multiple modules to restrict using gitignore-style
patterns or regular expressions.
_https://eslint.org/docs/latest/rules/no-restricted-imports#patterns_
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
this seems to show a decent speed up on perf.
the thinking behind this change is:
1. subsequent calls to `search_original_line_and_column` will **never**
look at back at lines it has already searched
2. binary search is faster in this case as typically `idx` is only
increased by a small amount
Given this, we can skip checking a bunch of lines (that will never
return true) improving performance.
This is a very hot path.
```
$ hyperfine --warmup=3 ./target/release-with-debug/examples/sourcemap-main ./target/release-with-debug/examples/sourcemap
Benchmark 1: ./target/release-with-debug/examples/sourcemap-main
Time (mean ± σ): 79.5 ms ± 5.5 ms [User: 65.1 ms, System: 12.2 ms]
Range (min … max): 76.8 ms … 111.7 ms 37 runs
Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
Benchmark 2: ./target/release-with-debug/examples/sourcemap
Time (mean ± σ): 72.9 ms ± 0.9 ms [User: 59.2 ms, System: 12.2 ms]
Range (min … max): 70.6 ms … 75.0 ms 40 runs
Summary
./target/release-with-debug/examples/sourcemap ran
1.09 ± 0.08 times faster than ./target/release-with-debug/examples/sourcemap-main
```
---------
Co-authored-by: overlookmotel <theoverlookmotel@gmail.com>
Add `Expression::into_inner_expression`. Does the same as `get_inner_expression` and `get_inner_expression_mut`, but operates on an owned `Expression`.
We don't transform private accessors yet, but include them in private property resolution.
This fixes some panics in TS conformance tests which use private accessors.
We don't transform private methods yet, but in class properties transform, still need to record private methods that classes have, so can correctly resolve private fields.
```js
class Outer {
#foo = 123;
method() {
class Inner {
#foo() {}
// Refers to `Inner`'s `#foo` method, not `Outer`'s `#foo` property
prop = this.#foo;
}
}
}
```
This PR implements folding `foo === undefined || foo === null` into `foo
== null`.
I checked the minified output diff this time, so hoping that there isn't
a bug.
Add failing test for nullish coalescing operator. The output is correct, but temp var is created in wrong scope.
My guess is that it needs to use `current_hoist_scope_id`, not `current_scope_id`.
This test from class properties also shows the same problem: ac097e9160/tasks/transform_conformance/snapshots/oxc.snap.md (L20-L35)
Large re-architecting of class properties transform. Split transform into 3 phases:
1. Transform instance properties when entering class.
2. Transform private fields during traversal of class body.
3. Transform static properties and static blocks when exiting class.
This ensures that code which has to be moved outside of the class (static property initializers, static blocks, computed keys) can get transformed by other transforms before they're moved out.
Also fixes a problem where we previously registered private properties too early - on entering the class, rather than the class *body*, so private fields in `extends` clause of a nested class were misinterpretted.
Record "block" scope ID along with "hoist" scope ID in `Traverse`.
"Block" scope is the scope where a `let` statement would be inserted above current position in AST.
Block scope and current scope differ from each other inside classes. For example, if want to create a `let` temp var for `foo()` or `bar()` in example below, should use block scope not current scope. Current scope is the class itself, but the `let` statement will be inserted *outside* the class.
```js
class C {
[foo()]: bar();
}
```
All transforms which create `let` bindings should use block scope not current scope. We should add `VarDeclarationsStore::insert_let` method which uses block scope, to accompany `insert_var` (which uses hoist scope).
This is implemented in a rather hacky way, and we should improve it later. Notably, we're not considering `for` statements as block scopes because we currently have no way to insert `let` statements into them if they don't have a body block.
