First of a series of PRs removing `new` and `new_with_scope_id` etc methods from AST types. Following #6760, all AST node creation can now go via the AST builder.
This lays groundwork for Node IDs (#5689), as we'll need `NodeId`s to be generated in `AstBuilder`, so that all nodes receive an ID.
Continue work on #4742.
Only `oxlint --print-config all` is supported. It's useful to migrate from command-line interface to config file.
The `--print-config PATH` looks not really useful for us now, I will add it after config file overrides supported.
#6740 and #6744 removed visitor type aliases (`#[visit(as(ClassHeritage))]`). Remove support for `#[visit(as(...))]` from `oxc_ast_tools`, since it's now dead code.
The previous version of the `react-perf` ESLint plugin was holding us
back from updating this to ESLint V9. I've manually specified the ESLint
version here, because we want to make sure we are running the latest
major version of ESLint which changes a lot of things.
Also changed it so that rules which are not supported and also
implemented do not get counted twice in the total count. For example,
`eslint/no-with` is marked as not supported but it is still implemented.
This was previously counted for both, which made it look like we had an
additional rule implemented.
closes#6736
There may be a better solution. If there is a good way to fix it, please
feel free to close it. I will fix the clippy problem later because I
went back to the dormitory to sleep and my computer was in the studio.
---------
Co-authored-by: Don Isaac <donald.isaac@gmail.com>
Add methods to `AstBuilder` to create AST nodes with `ScopeId`, `SymbolId`, `ReferenceId`, for use in transformer.
e.g. `identifier_reference_with_reference_id`, `binding_identifier_with_symbol_id`, `block_statement_with_scope_id `.
Theory: iterating over the rules three times has slightly worse cache locality, because the prior iterations have pushed `rule` out of the cache by the time we iterate over it again. By iterating over each rule only once, we improve cache performance (hopefully). We also don't need to collect rules to a Vec, so it saves some CPU/memory there too.
In practice: the behavior here actually depends on the number of AST nodes that are in the program. If the number of nodes is large, then it's better to iterate over the nodes only once and iterate the rules multiple times. But if the number of nodes is small, then it's better to iterate over nodes multiple times and only iterate over the rules once. See this comment for more context: https://github.com/oxc-project/oxc/pull/6600#issuecomment-2427837715, as well as the comment inside the PR: https://github.com/oxc-project/oxc/pull/6600/files#diff-207225884c5e031ffd802bb99e4fbacbd8364b1343a1cec5485bf50f29186300R131-R143.
In practice, this can make linting a file 1-45% faster, depending on the size of the file, number of AST nodes, number of files, CPU cache size, etc. To accommodate large and small files better, we have an explicit threshold of 200,000 AST nodes, which is an arbitrary number picked based on some benchmarks on my laptop. For large files, the linter behavior doesn't change. For small files, we switch to iterating over nodes in the inner loop and iterating over rules once in the outer loop.
`LintContext` contains many wrapper methods that invoke a method with the same
name on `Semantic`. Implementing `Deref` lets us remove those redundant methods.
Follow-on after #5774. Correct the logic for calculating niches in enums.
It's still not quite correct - number of niches depends on how many spare discriminant "slots" there are at *start or end* of the range, not in total. But this is closer to correct than it was - we now don't take into account whether enum variant payloads have niches or not, which is not relevant.
Fixes a bug with how we were calculating the size of enums when there are different padding on variants and there aren't enough niches. Now it aligns the largest variant size to the largest alignment before consuming niches.
Pure refactor. It makes more sense to me for `Address` and `GetAddress` to be defined in the same place. Also then we can use the trait for `impl GetAddress for Box`.
Preparation for #6141
`oxc_regular_expression` can already parse and validate both `/regexp-literal/` and `new RegExp("string-literal")`.
But one thing that is not well-supported was reporting `Span` for the `RegExp("string-literal-with-\\escape")` case.
For example, these two cases produce the same `RegExp` instances in JavaScript:
- `/\d+/`
- `new RegExp("\\d+")`
For now, mainly in `oxc_linter`, the latter case is parsed with `oxc_parser` -> `ast::literal::StringLiteral` AST node -> `value` property.
At this point, escape sequences are resolved(!), `oxc_regular_expression` can handle aligned `&str` as an argument without any problem in both cases.
However, in terms of `Span` representation, these cases should be handled differently because of the `\\` in string literals...
As a result, the parsed AST's `Span` for `new RegExp("string-literal")` is not accurate if it contains escape sequences.
e.g. a01a5dfdaf/crates/oxc_linter/src/snapshots/no_invalid_regexp.snap (L118-L122)
Each time the `\` appears, the subsequent position is shifted. `_` should be placed under `*` in this case.
So... to resolve this issue, we need to implement `string_literal_parser` first, and use them as reading units of `oxc_regular_expression`.
