Improved the error message when JSX syntax is found while not enabled.
The idea came from esbuild's error message ([esbuild try](https://esbuild.github.io/try/#dAAwLjI3LjAAAGV4cG9ydCBjb25zdCBmb28gPSA8Rm9vIC8+Ow)).
**Before**
```
x Unexpected token
,-[:1:20]
1 | export const foo = <Foo />;
: ^
`----
```
**After**
```
× Unexpected JSX expression
╭─[misc/fail/jsx-in-js.js:1:20]
1 │ export const foo = <Foo />;
· ───────
╰────
help: JSX syntax is disabled and should be enabled via the parser options
```
Improves error message for imbalanced tokens.
```
× Expected `,` or `]` but found `const`
╭─[misc/fail/imbalanced-array-expr.js:2:1]
1 │ const foo = [0, 1
· ┬
· ╰── Opened here
2 │ const bar = 2
· ──┬──
· ╰── `,` or `]` expected
╰────
```
The error message for this case was:
```
x Expected `,` but found `const`
,-[:2:1]
1 | const foo = [0,1
2 | const bar = 2
: ^^|^^
: `-- `,` expected
`----
```
This change makes it clear why the parser is expecting `,` and also tell that it can be fixed by adding the closing token somewhere.
Improve error message for missing alternative for conditional expressions.
```
× Expected `:` but found `EOF`
╭─[misc/fail/missing-conditional-alternative-type.ts:2:1]
1 │ type A = 1 extends 2 ? 3
· ┬
· ╰── Conditional starts here
╰────
× Expected `:` but found `EOF`
╭─[misc/fail/missing-conditional-alternative.js:2:1]
1 │ const foo = 1 ? 2
· ┬
· ╰── Conditional starts here
╰────
```
Without this PR, the error mesage is a simple ``Expected `:` but found `EOF` `` only.
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
},
};
}
}
```
See https://babel.dev/docs/options#misc-options for background on `unambiguous`
Once `SourceType::Unambiguous` is parsed, it will correctly set the returned `Program::source_type` to either `module` or `script`.
Closes#5177
While making this, I noticed an uncaught parse error for accessors: accessors cannot be optional. I'll add a fix for this in an up-stack PR.
sapphi-red