In particular:
* the long comment was scrolling off side of screen on
[npm.com](https://www.npmjs.com/package/oxc-parser).
* the example is ESM, so can simplify it by using top level await.
These two APIs are used to create a symbol with the provided symbol name, The difference from `generate_uid` is that we don't need to create a unique name for the symbol.
If you have a better method name for this, Feel free to edit this PR directly
Style nit. Dereference `&ScopeId` to `ScopeId` as early as possible. `&ScopeId` is 8 bytes, whereas `ScopeId` is 4 bytes.
In simple cases like this, compiler will optimize it anyway, but still I think it's a better pattern to dererence early. In more complicated cases, it will be better for performance, and in my opinion, it makes things clearer if vars called `scope_id` are always a `ScopeId`, not sometimes a `&ScopeId`.
Store `BoundIdentifier` in `registrations`. This allows removing the call to `ctx.ast.atom()` which re-allocates a new `Atom` into the arena - unnecessary as it's already been allocated when the UID was created.
It's unfortunate that `Semantic` stores symbol names as `CompactStr`s instead of `Atom`s, otherwise we could get the name as an `Atom` without re-allocating it. Hopefully we can make that change in future, and then reduce `BoundIdentifier` to just contain the `SymbolId`. But for now, we are kind of stuck with it.
Style nit. Dereference `&SymbolId` to `SymbolId` as early as possible. `&SymbolId` is 8 bytes, whereas `SymbolId` is 4 bytes.
In simple cases like these, compiler will optimize it anyway, but still I think it's a better pattern to dererence early. In more complicated cases, it will be better for performance, and in my opinion, it makes things clearer if vars called `symbol_id` are always a `SymbolId`, and not sometimes a `&SymbolId`.
Style nit. Dereference `&ScopeId` to `ScopeId` (and other IDs) as early as possible. `&ScopeId` is 8 bytes, whereas `ScopeId` is 4 bytes.
In simple cases like these, compiler will optimize it anyway, but still I think it's a better pattern to dererence early. In more complicated cases, it will be better for performance, and in my opinion, it makes things clearer if vars called `scope_id` are always a `ScopeId`, not sometimes a `&ScopeId`.
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.
