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.
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.
