## Summary
Introduces `oxc_diagnostics::Diagnostics` — a `Vec<OxcDiagnostic>` newtype that knows the difference between errors and warnings — and makes it the standard diagnostics return value across oxc.
- **New type**: `Diagnostics` with `has_errors()`, `has_warnings()`, `errors()`, `warnings()`, plus `Vec`-like ergonomics (Deref, `IntoIterator`, `Extend`, `From`/`Into<Vec>`) so most call sites are unchanged.
- **Return types**: `ParserReturn`, `SemanticBuilderReturn`, `IsolatedDeclarationsReturn`, the React Compiler `TransformResult`/`LintResult`, and `TransformerReturn` now expose `diagnostics: Diagnostics` instead of `errors: Vec<OxcDiagnostic>` (the React Compiler's separate `errors`/`warnings` are merged into one severity-tagged list).
- **Behaviour**: a React Compiler **error** now stops the transform (no output), while **warnings** flow through and the transform continues. `compile()` aborts codegen only when `diagnostics.has_errors()` — warnings alone no longer abort (previously any diagnostic did).
## Breaking change
Consumers reading `*.errors` on these return values must read `*.diagnostics`. React Compiler consumers that read `.errors`/`.warnings` separately should use `diagnostics.has_errors()` / `diagnostics.errors()` / `diagnostics.warnings()`.
Parser/semantic/isolated-declarations fatality is otherwise unchanged. Builds on the React Compiler transform feature (#23201).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Tab may be lost when copying from the terminal, which makes it hard for us to use https://source-map-viewer.void.app for inspection. So change it to space.
~~wanted to have a shot at implementing this, this is rough draft.~~
~~Dunqing or overlookmotel feel free to take over or close out this PR. not sure how much time i'll have to finish it off~~
@Dunqing @overlookmotel this should be ready when you guys have time 🙏closes#9168
Replace `#[allow]` with `#[expect]` through the whole codebase.
This also surfaced many places where the `#[allow]` attributes were outdated/pointless and could be removed entirely.
Only places `#[allow]` remains are:
1. In generated code and macros, where lint errors may or may not be triggered depending on the generated code.
2. A few places where clippy malfunctions. These use e.g. `#[allow(unused, clippy::allow_attributes)]`.
Sometimes we want to use Babel test's options to test some code, If the example can get the TransformerOptions from Babel options, then we can easily do it
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) {
};
```
Boshen