Detect types such as `Cell<Option<ScopeId>>` and mark them as such! We didn't used to use this method for these options but now we have to check all types to calculate their layouts which means we need to process them correctly(instead of falling to their inner value).
Closes#4606.
Introduce `GetSpanMut` trait and implement it on all AST node types.
This has to be a separate trait, rather than adding `span_mut` method to `GetSpan` because `AstKind` implements `GetSpan`, and it only has an immutable `&` ref to AST node it contains.
In `AstBuilder`'s `alloc_*` methods, use `Box::new_in` instead of `.into_in`. This is more explicit, so I feel easier to understand. It may also make life easier for compiler by not requiring it to perform type coercion.
Mark everything mentioned in https://github.com/oxc-project/oxc/pull/3815#issuecomment-2186736258 as AST.
We now error on the occurrence of non-ast items in the source of truth. It doesn't make sure that all fields and variants are `#[ast]` and therefore `repr_stable` but there are only a handful of non-AST types used here(mainly Atom and Span). Since we don't have access to the external types we can't make sure of it unless we find a way to const assert it.
The best we can do until then is to check all field/variant types to be either `#[ast]` or in a white list. I can add this check to the codegen in an upcoming PR.
Add `#[inline]` to empty default implementations of `enter_node` etc. Hopefully compiler will inline them automatically within Oxc even cross-crate because we compile with LTO, but maybe not for external consumers who don't use LTO.
close: #3969close: #2023
We need to add scope according to [this](d8086f14b6/src/compiler/binder.ts (L3883-L3962)). There are still some ASTs that need to be added to the scope.
---
Context from @Boshen:
Before this whole journey of fixing symbols and scopes I asked @Dunqing to debug through binder.ts via a debugger to fully understand how it does resolution.
We then agreed to align the implementation so that when a problem occurs, we can debug through both implementations and find where our problem is.
tsc doesn't have a specification, so we need to align with the reference implementation instead.
We have a strange workaround for `visit_function` where we pass in `ScopeFlags`, to support creating the scope inside `Function`, but setting different flags for `MethodDefinition`s.
Previously `visit_function` took `Option<ScopeFlags>` and then did `flags.unwrap_or(ScopeFlags::empty()) | ScopeFlags::Function` to it. Personally, I found this confusing. When I was looking at `MethodDefinition`, I was wondering "It's a function, why doesn't it set Function flag too?"
This changes makes it more explicit and clear what `ScopeFlags` everything has.
I'm going to be AFK today(till about 9 PM UTC). Meanwhile, I Didn't want to be a blocker so here we go.
It would fix the #4200 merge if you guys find it in the correct order otherwise feel free to close it.
```
Usage: oxc_ast_codegen [--dry-run] [--no-fmt] [--schema=ARG]
Available options:
--dry-run Runs all generators but won't write anything down.
--no-fmt Don't run cargo fmt at the end
--schema=ARG Path of output `schema.json`.
-h, --help Prints help information
```
hotfix for #4060
I just added an edge case, We can come back to it later on and make it a
standard in our codegen.
The diff is big because it causes the code to reorder, The edge case
generated code doesn't follow the order in which they are defined in the
source of truth(eg `js.rs`)
~~Attempt to improve the performance of visitors, It is mostly for experiments. I'm not sure how much performance is there to gain back.~~
- [x] inline plural visits (eg: visit_statements)
- [x] inline enums when there are 5 or fewer match cases
- [x] inline structs when there are 5 or less fields
- [x] inline `Visit::alloc`
~~The generated code is only here for the sake of my own comparison (instead of manually keeping a backup of the old generated file). I would clean this up as soon as it is ready, submit some parts of it as the down stack, and stack the actual generated code on top of this. So please don't let the huge diff distract you, It won't have many conflicts since almost all of these are the generated visit code, which is completely contained to its own module(other than some minor renaming refactors).~~
The order of function definitions is a bit different, I've used a depth-first search, We can switch to a breadth-first one to align functions more closely to the original.
We use prettyplease for formatting our generated code, Which has a lot of advantages over rustfmt, But sometimes it conflicts with our cargo fmt config,
Since it isn't configurable I just added a `cargo fmt` step after the generation process to prevent conflicts.
We might be able to not rely on prettyplease at all, But We have to test that one after we have most of our generated code, rustfmt usually bails on nested calls and macros so it might not work as our only solution. In contrast to that prettyplease is used in both bindgen and cargo-expand and is created for this exact reason(formatting generated code).
