Add `SemanticBuilder::with_excess_capacity` method to request that `SemanticBuilder` over-allocate space in `Semantic`'s `Vec`s.
Use this method to reserve 200% extra capacity for transformer to create more scopes, symbols and references.
200% is an unscientific guess of how much extra capacity is required. Obviously it depends on what transforms are enabled and content of the source code.
Realized we can get the source type from the AST.
The next PR will introduce `unambiguous` to `SourceType` and directly set `Program::source_type` to either `script` or `module`.
We no longer need to build semantic data inside the transformer.
The caller should be responsible for handling semantic data and its
errors.
The best way to achieve this in via `CompilerInterface`.
closes#3565
This PR introduces two type alias to avoid the confusing const generic `pub struct Codegen<'a, const MINIFY: bool>`
* CodeGenerator - Code generator without whitespace removal.
* WhitespaceRemover - Code generator with whitespace removal.
Usage is changed to a builder pattern:
```rust
CodeGenerator::new()
.enable_comment(...)
.enable_sourcemap(...)
.build(&program);
```
It seems like we need to rebuild the scopes and symbols while
traversing. We can't utilize the scopes and symbols built by semantic
because they are immutable.
- Adds option to `CodegenOptions` - `enable_typescript` to enable output
of TS.
- Stops skipping output that is TS when `enable_typescript` is enabled
- Adds TS support to
- Function
- FormalParameter
- BindingPattern
- Adds basic tests for TS generation
---------
Co-authored-by: Boshen <boshenc@gmail.com>
@Boshen
The `ScopeTree.descendants` function would return all scopes starting
from the root, and wasn't truly descendants from a specific scope. To
improve this, I've renamed this function to `descendants_from_root` and
have introduced a new `descendants` function that does support from a
specific scope.
Furthermore, I've introduced helper functions to `SymbolTree` to make
reading symbols/scopes easier.
To verify this functionality, I enabled the `function_name` transformer
(and fixed it), and ran some example transforms. Here's the input:
```js
let fn;
fn = function (a, b, c) {
const d = "";
};
const func = function (arg) {
{
const value = "";
}
};
const f = function (f) {};
```
And the output using _the old implementation_. Note that all function
names are suffixed with a number, this is incorrect, since it was
inheriting far too many scopes.
```js
let fn;
fn = function fn1(a, b, c) {
const d = '';
};
const func = function func1(arg) {
{
const value = '';
}
};
const f = function f2(f) {
};
```
And here's the output with the new implementation. Note that only `f` is
suffixed with a number. That's because it has a shadowed argument of the
same name.
```js
let fn;
fn = function fn(a, b, c) {
const d = '';
};
const func = function func(arg) {
{
const value = '';
}
};
const f = function f1(f) {
};
```
