Avoid the `insert!` macro in AST codegen. Use doc comments starting with special symbol `@` instead.
* Before: `insert!("// plain comment");`
* After: `///@ plain comment`
* Or: `//!@ plain comment`
Either `///@` or `//!@` is converted to plain `//` in output.
`//!@` is legal in top-of-file position, which allows us to inline `#![allow(...)]` attributes, which in my opinion makes the generators a bit easier to read.
#4773 makes types like `Span` importable from `oxc_ast::ast`, so remove the imports from other crates in generated code.
I'm not sure why clippy's `wildcard_imports` rule was not being triggered for `use crate::ast::*;`, but add `#[allow(clippy::wildcard_imports)]` on these statements just to make sure.
follow-up to #4735
I was accidentally using the old code to filter the viable target types to derive. It means before this PR we were still using the `#[ast(visit)]` for this purpose.
Remove `Generator::name` and `Pass::name` methods. All impls for these methods return a string identical to the struct name, so can set return value of `Runner::name` in `define_generator!` and `define_pass!` macros instead.
Simplify `derive_get_span` generator that was introduced in #4735. No change to functionality, just aiming for greater readability.
In particular:
* Move defining idents/tokens which are specific to `GetSpan` / `GetSpanMut` into those specific generators, rather than branching on `MUT` later on.
* Remove `const MUT` param.
* Remove the confusing pairs of closures and functions both called `derive_enum` / `derive_struct`.
* Inline function which generates the impls - prioritizing readability over DRY code.
This PR introduces `EarlyCtx` and `LateCtx` in place of the old `CodegenCtx`, Early passes operate at the AST level while generators and other late passes operate on the schema.
It will also replace the confusing `RType` name with something more idiomatic ~~(open for suggestions, I haven't found a good name yet)~~ I've named it `AstType` and dropped the `R` prefix for `REnum` and `RStruct`.
There are some qualities of life improvements too, Things like `to_type_elide` can be used to simplify the code.
Related to #4442 (and can potentially mark it "close as fixed").
Introduce new method `ConcatSourceMapBuilder::from_sourcemaps`.
Where all the sourcemaps being concatenated exist at time that you
create `ConcatSourceMapBuilder`, it's faster to use `from_sourcemaps`,
because it pre-allocates enough space for the data it will hold and so
avoids memory copying.
Before:
```rs
let mut builder = ConcatSourceMapBuilder::default();
builder.add_sourcemap(&sourcemap1, 0);
builder.add_sourcemap(&sourcemap2, 100);
builder.add_sourcemap(&sourcemap3, 100);
let combined = builder.into_sourcemap();
```
After:
```rs
let builder = ConcatSourceMapBuilder::from_sourcemaps(&[
(&sourcemap1, 0),
(&sourcemap2, 100),
(&sourcemap3, 200),
]);
let combined = builder.into_sourcemap();
```
When we move all the bindings in the CatchClause scope to its child scope (BlockStatement), we also need to replace the scope_id in the symbol with the scope_id of the new scope.
Closes#4085
This issue seemed to have been addressed in #3779 , but partially
reverted in #3813 ? 🤔
Since I wasn't aware of these changes, I've just checked the current
implementation through the review requests in #4611 and refactored as
the original author.
After studying google closure compiler, I'm leaning towards a multi-ast-pass infrastructure for the minifier.
This is one of the few places where we are going to trade maintainability over performance, given the goal of the minifier is compression size not performance.
All of the terminologies and separation of concerns are aligned with google closure compiler.
Infrastructure of `terser` and `esbuild` are not suitable for us to study nor pursuit. Their code are so tightly coupled - I failed to comprehend any of them every time I try to walk through a piece of optmization. Google closure compiler despite being written in Java, it's actually the most readable minifier out there.
To improve performance between ast passes, I envision a change detection system over a portion of the code.
The benchmark will demonstrate the performance regression of running 5 ast passes instead of 2.
To complete this PR, I need to figure out "fix-point" and order of these ast passes.
part of #4549
This test verifies that the correct symbols and scopes were added/changed during the transformation. From the snapshots, most of them are incorrect currently
