Closes#6358
@preyneyv I know you've been working on this problem.
This is an implementation that has been dormant on my local for a while.
- All tests are passing
- However, the approach is simple but not general, so there might be some edge cases that were missed
- There's also room for improvement in terms of performance
For these reasons, it was marked as WIP for me.
I believe the test cases and other parts are usable, so feel free to fork and replace them with your implementation if you'd like.
> Closes#6750
Fixes a false positive in `react/iframe-missing-sandbox` on `document.createElement`, which is not react and has no way of passing a sandbox prop/attribute on creation.
- Added TypeScript annotation for `ParseResult.program`
- Modified the entrypoint for `oxc-parser` to allow wrapping the napi functions
- Updated `index.js` to parse the `program` string into a JSON object
- Updated tests
- Added a dependency on `@oxc/types`
This makes the use of `Address` an internal implementation detail of `StatementInjectorStore`. The caller shouldn't need to care about how `StatementInjectorStore` achieves its work. In future it might use `NodeId`, for instance.
We could broaden this in future so these methods take a `&A where A: GetAddress` if we need to, but for now taking a `&Statement` seems OK.
Follow-up after #6830.
Now that `generate_binding` doesn't need access to `AstBuilder`, it can move into `TraverseScoping`.
Occasionally this is helpful when you need to borrows 2 parts of `TraverseCtx` simultaneously. e.g.:
```rs
// This fails to compile because we try to mutably borrow `TraverseCtx`
// while it's already borrowed
if let Ancestor::ProgramBody(body) = ctx.parent() {
// ^^^ immutable borrow
let binding = ctx.generate_binding(name, scope_id, flags);
// ^^^ mutable borrow
}
// Borrow-checker allows this because we borrow fields of `TraverseCtx` separately
if let Ancestor::ProgramBody(body) = ctx.ancestry.parent() {
let binding = ctx.scoping.generate_binding(name, scope_id, flags);
}
```
Follow-up after #6805.
`TraverseCtx::generate_binding` take an `Atom` instead of a `CompactStr`. If it's an existing var name (which it must be, otherwise we'd be using `TraverseCtx::generate_uid`), an `Atom` will already exist in the arena for this symbol name, so we'd be better off reusing it, rather than writing the same `Atom` into the arena again.
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.
