Fixes a bug in #3229.
The logic to prevent a duplicate scope being created for a `Function` which is a `MethodDefinition` would also stop a scope being created for inner function in:
```rs
class X {
foo() {
function bar() {}
}
}
```
or
```rs
class X {
foo( bar = function() {} ) {}
}
```
This PR fixes that. This change also allows removing `ScopeFlags::Method` which #3229 added.
Add scope flags to `TraverseCtx`.
Closes#3189.
`walk_*` functions build a stack of `ScopeFlags` as AST is traversed, and they can be queried from within visitors with `ctx.scope()`, `ctx.ancestor_scope()` and `ctx.find_scope()`.
The codegen which generates `walk_*` functions gets the info about which AST types have scopes, and how to check for strict mode from the `#[visited_node]` attrs on AST type definitions in `oxc_ast`.
A few notes:
Each scope inherits the strict mode flag from the level before it in the stack, so if you need to know "am I in strict mode context here?", `ctx.scope().is_strict_mode()` will tell you - no need to travel back up the stack to find out.
Scopes do *not* inherit any other flags from level before it. So `ctx.scope()` in a block nested in a function will return `ScopeFlags::empty()` not `ScopeFlags::Function`.
I had to add an extra flag `ScopeFlags::Method`. The reason for this is to deal with when a `Function` is actually a `MethodDefinition`, and to avoid creating 2 scopes in this case. The principle I'm trying to follow is to encode as little logic in the codegen as possible, as it's rather hidden away. Instead the codegen follows a standard logic for every node, guided by attributes which are visible next to the types in `oxc_ast`. This hopefully makes how `Traverse`'s visitors are generated less mysterious, and easier to change.
The case of `Function` within `MethodDefinition` is a weird one and would not be possible to implement without encoding a magic "special case" within the codegen without this extra `ScopeFlags::Method` variant. Its existence does not alter the operation of any other code in Oxc which uses `ScopeFlags`.
In my view `ScopeFlags` might benefit from a little bit of an overhaul anyway. I believe we could pack more information into the bits and make it more useful.
I've tried too hard to make it into a full-fledged depth first iterator, But had no success with it; It is the next best thing that I could've thought of.
Provides a way to visit the module graph from a ModuleRecord as its entry point.
# What This PR Does
Symbols declared inside exported functions and classes were being
incorrectly flagged with `SymbolFlags::Export`.
For example,
```ts
export function foo<T>(a: T) {
let b = String(a)
return b
}
```
`T`, `a`, and `b` were all flagged as exported.
## Further Work
It doesn't seem like exported enums and interfaces are being included in
`ModuleRecord`. Am I looking in the wrong place, or are they actually
missing?
This PR merges the previous confusing features `serde` and `wasm` into a
single `serialize` feature.
We'll eventually do serialize + type information for both wasm and napi
targets.
`oxc_macros` is removed from `oxc_ast`'s dependency because it requires
`syn` and friends, which goes against our policy ["Third-party
dependencies should be
minimal."](https://oxc-project.github.io/docs/contribute/rules.html#development-policy)
Closes#2641.
Also added `tsify` attribute to the `SerAttrs` derive macro, so `#[cfg_attr(feature = "wasm", tsify(...))]` can also be reduced to `#[tsify(...)]`.
Pure refactor. Import `tsify::Tsify` in files that use it, so then shorten a load of:
```diff
- #[cfg_attr(feature = "wasm", derive(tsify::Tsify))]
+ #[cfg_attr(feature = "wasm", derive(Tsify))]
```
Preparatory step for #2620.
This PR purely changes names of types and methods:
* `CompactString` -> `CompactStr`
* `Atom::to_compact_string` -> `to_compact_str`
* `Atom::into_compact_string` -> `into_compact_str`
Have split this into a separate PR as the diff is large, but it does absolutely nothing but renaming (I've checked the whole diff twice, so feel free not to check it again!). This should make it easier to see the content of the substantive change in #2620.
This gets all the new TS types working to the same level TS output was
before and fixes a bunch of other codegen
---------
Co-authored-by: Boshen <boshenc@gmail.com>
A small nit: `ASCII_CONTINUE` is used in multiple places, so it's
preferable that it's a `static` not a `const` so it only gets included
in the binary once, rather than once for each usage.
Only makes a tiny difference on benchmarks (~0.1 ms), but change seems
worthwhile anyway just to be more "good practice".
