Do not know if the parser is wrong, or the description of `TSTypeAnnotation`:
```
pub struct TSTypeAnnotation<'a> {
/// starts at the `:` token and ends at the end of the type annotation
pub span: Span,
/// The actual type in the annotation
pub type_annotation: TSType<'a>,
}
```
having this code:
`tasks/coverage/babel/packages/babel-parser/test/fixtures/typescript/assert-predicate/function-declaration/input.ts`
```
function asserts1 (value: unknown): asserts value is string {}
function asserts2 (value: unknown): asserts value {}
function asserts3 (value: unknown): asserts {}
```
there are 2 `TSTypeAnnotation`s here:
<img width="928" height="912" alt="grafik" src="https://github.com/user-attachments/assets/b0d12446-7e6b-4e59-a426-8eee9d7f2bb0" />
in `tasks/coverage/babel/packages/babel-parser/test/fixtures/typescript/interface/extends/input.ts`
```
interface I extends X.Y<Z> {}
```
was formatted to
```
interface I extendsX.Y<Z> {}
```
This PR aims to remove the special logic for import and export declarations from `get_trailing_comments` and move the special logic to the printing site. The benefits of this are to make `get_trailing_comments` cleaner so that we can entirely remove `SiblingNode`, which may lead to significant performance improvements.
Fixes https://github.com/rolldown/rolldown/issues/6079. Regressed introduced by https://github.com/oxc-project/oxc/pull/13227.
The root cause is that the class plugin will insert a constructor method in some cases, but metadata handling is processed before the constructor is inserted, which causes the method count not to be exactly the same as the method metadata count. Thus, decorator metadata is inserted in the incorrect place.
This PR refactors the core transformation logic to ensure that the new methods and properties inserted by other plugins won't affect the decorator transformation.
### Transformation Flow Changes
Before: Complex upfront analysis with separate processing paths
- Used check_class_has_decorated() to analyze entire class tree
- Separate handling for class vs element decorators
- Multiple disconnected stacks for state tracking
After: Unified incremental processing
- Process decorators as we traverse (exit_method_definition,
exit_property_definition, etc.)
- Accumulate decoration statements in single stack during traversal
- Unified processing in transform_class() using consolidated state
For this input given:
```js
async function m() {
({ x } = await foo());
({ y } = foo());
}
```
Currently formatted as:
```js
async function m() {
{ x } = await foo();
{ y } = foo();
}
```
This is invalid syntax.
Fixes#13284.
Fix semantic's checking of `super()` and `super.prop`.
This fixes various TS test cases, notably correctly identifying that these are all illegal:
```js
class C {
prop = function() { super.foo };
[super.foo]() {}
@super.foo method() {}
};
```
It also fixes various edge cases related to classes nested within other classes that aren't covered by existing conformance tests.
It's pretty much a complete re-write. I've combined the 2 paths for in a class and not in a class into one, to avoid repeated code.
This PR includes pass + fail test fixtures which include `super` in every conceivable position I could think of. There are so many errors in the fail test fixtures, that I had to write a script to check the snapshot includes them all!
Hopefully this solves this issue for once and for all!
Note: The large pass fixture seems to be revealing bugs somewhere in transformer - there's a mismatch, as well as lots of wrong scopes. But that's incidental to this PR, and can be addressed separately.
Follow up to #13368.
Closes#11713 by fixing five more cases mentioned in
https://github.com/oxc-project/oxc/issues/11713#issuecomment-3239687597.
Other changes:
- Added TS(1024) diagnostic
- Fixed the broken oxc-11713-13.ts test file
- Made TS(1070) not report redundantly if it's actually the
responsibility of TS(1071)
- Branch off the more specific TS(1028) diagnostic from the general
TS(1030) diagnostic like TypeScript does
- Remove incorrect code to parse modifiers on typescript this parameter
Closes#12816.
Alternative to #13460.
This PR is the slightly cleaner way to fix the issue compared to the
other PR, but comes at a potential performance cost because now instead
of remembering how many errors there were, we are storing a clone of all
errors and re-assign them when rewinding.
This makes it possible to fix the issue because now even errors before a
checkpoint, that were popped/removed after the checkpoint, are properly
rewinded.
### Changes
- Added all 22 examples of #11713 to `tasks/coverage/misc/fail`
- Added `Default` and `Export` to modifiers
- Added three new TS diagnostics: 1029, 1031, and 1070
- Split off `FunctionKind::Constructor` from `FunctionKind::ClassMethod`
to differentiate when verifying modifiers of formal parameter
- Added multiple checks to verify modifiers
### Results
- "Negative Passed" percentage of `parser_babel.snap` and
`parser_typescript.snap` increased
- Better diagnostic messages in both snapshots
- All new failing examples of original issue do really fail
- Closes#11713
---------
Co-authored-by: Boshen <boshenc@gmail.com>
closes#13284
Either TypeScript implemented the spec incorrectly or made it more
strict.
```js
class C {
foo() {
return {
bar() {
super.bar(); // syntax error in ts but not in js
},
};
}
}
```
Fixes: https://github.com/oxc-project/oxc/pull/13215#pullrequestreview-3132979634
Collect metadata and store them in a `VecDeque`, and take them when transforming the class decorators in the `exit_class` side, which can eliminate the unreliable check of `span.is_unspanned` for metadata decorators. However, it introduces a little complexity.
Similar to #13122. Unconditionally initialize Rayon global thread pool in coverage runner.
The guarantees provided by explicitly initializing the thread pool are going to be critical for the linter.
Coverage currently doesn't cover linter, so it doesn't matter, but this doesn't hurt to do, and gives us greater safety if coverage does involve the linter at a later date.
* Fixes#13009
The optimization that converts `{...props}` to `props` when it's the only attribute was incorrectly applied even when `jsx_self` or `jsx_source` plugins are enabled. This caused `__self` and `__source` props to not be merged properly,
resulting in incorrect transformation output in development mode.
This fix disables the optimization when these dev plugins are active, ensuring spread props are preserved for proper merging.
We can now use `if let` chains. Previously we had to use an early return pattern in some places because one branch had multiple nested `if` statements. Now that they're combined into a single `if`, we don't need to use this pattern any more, and can convert to `if` / `else`. Usually this is shorter, but even when it's not, in my opinion it's a bit clearer.
Dunqing