You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SWC's interpretation of type arguments in TypeScript code is different than the TypeScript compiler, which can cause SWC to generate incorrect JavaScript.
SWC should produce this to match the TypeScript compiler:
fn(x<y,x>=y);
Actual behavior
SWC produces this instead, which is incorrect:
fn(x=y);
Version
1.3.57
Additional context
Specifically TypeScript's parseTypeArgumentsInExpression function backtracks unless the trailing > comes from a > real token. This is subtle because TypeScript's type argument parser normally strips off the leading > from a token, which is why >> works in a<b<c>>(d). But it turns out that should only be done when you're in a type context. When you're in an expression context, the trailing > must not come from a token that has anything else after it. So for example a<b<c>>=(d) should not be considered a type argument list because parseTypeArgumentsInExpression encounters a >= token.
I just fixed this bug in esbuild: evanw/esbuild#3111. I'm reporting it here because SWC appears to also have this issue. The bug does not introduce a syntax error, which means the problematic output might be missed before releasing it, so I considered this bug to be higher severity.
The text was updated successfully, but these errors were encountered:
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
Describe the bug
SWC's interpretation of type arguments in TypeScript code is different than the TypeScript compiler, which can cause SWC to generate incorrect JavaScript.
Input code
Config
(I only ran SWC via the playground)
Playground link
https://play.swc.rs/?version=1.3.57&code=H4sIAAAAAAAAA0vL06hQsFGo1FGoULCzVajU5AIAIT%2B1gxIAAAA%3D&config=H4sIAAAAAAAAA1VPOw7DIAzdOQXy3CHK0KF36CEQdSIqfsKOVBTl7oUE0maz38fveRVSwps0PORaxrJElQjTuReEsmf1KQhwjkg6mchw6yxTpSZlCXdoOxhglWbk6kIah3FoDrAhEHZHw5zxZsr%2FmTq4mJDoKqxS5WeL10TRUsGF17KT7Zfa92hwh5%2Boh52HwdCzOzktKLYvIO%2B2AhcBAAA%3D
Expected behavior
SWC should produce this to match the TypeScript compiler:
Actual behavior
SWC produces this instead, which is incorrect:
Version
1.3.57
Additional context
Specifically TypeScript's
parseTypeArgumentsInExpression
function backtracks unless the trailing>
comes from a>
real token. This is subtle because TypeScript's type argument parser normally strips off the leading>
from a token, which is why>>
works ina<b<c>>(d)
. But it turns out that should only be done when you're in a type context. When you're in an expression context, the trailing>
must not come from a token that has anything else after it. So for examplea<b<c>>=(d)
should not be considered a type argument list becauseparseTypeArgumentsInExpression
encounters a>=
token.I just fixed this bug in esbuild: evanw/esbuild#3111. I'm reporting it here because SWC appears to also have this issue. The bug does not introduce a syntax error, which means the problematic output might be missed before releasing it, so I considered this bug to be higher severity.
The text was updated successfully, but these errors were encountered: