>= or <= binary expression containing TS "as expression" fails to parse

[dsherret]

Describe the bug

Binary expressions with >= or <= operators containing a TypeScript "as expression" fail to parse.

Input code

const a = testNum as number >= 0 // or <=, but < and > are fine

Config

No response

Playground link (or link to the minimal reproduction)

https://play.swc.rs/?version=1.7.17-nightly-20240820.3&code=H4sIAAAAAAAAA0vOzysuUUhUsFUoSS0u8SvNVUgsVsgrzU1KLVKws1UwAAAPKf%2BNIAAAAA%3D%3D&config=H4sIAAAAAAAAA1WQvW7DMAyE9z6FoTmoCw8ZsrbIlilPQCh0w0J%2FICkgRuB3jyTHcbqJ3%2FF04N0%2Fus78iTWH7l6eZUjAgvyaC5EpKNwKMTolFMuU1OxWVaVKyhkbmRfBKPAvajWhDF%2FDYFbOEGSM7N8TsuAPjhTwGPnbgciR0F3k%2Be8rihGsvvkKIp8i6zlmtljDrqpJDn2P4j%2Fl2qfFstsMnIOSb7uQNXpQsuYpz%2F8ucDFK3RvBSb2tcePjJTvc6qqVLFfuzbZEgcZp9TZEclqdrav5AeQIxLB6AQAA

SWC Info output

No response

Expected behavior

Should parse

Actual behavior

  x Expression expected
   ,-[input.tsx:1:1]
 1 | const a = testNum as number >= 0
   :                              ^
   `----


Caused by:
    0: failed to process js file
    1: Syntax Error

Version

1.7.17-nightly-20240820.3

Additional context

No response

[magic-akari]

Should it be fixed in #9313 ?

[kdy1]

It will be fixed by #9313, but I expect #9313 to take lots of time, mainly because I don't have time to work on it

[magic-akari]

Investigation

In the SWC parser, the function read_token_lt_gt checks if the next token is either < or > and decides whether to process any following =. In in_type mode, it immediately returns either < or >.

In the next_then_parse_ts_type function, in_type is set to true to enter the TS type parsing mode.
However, this in_type mode also affects the next cache which used to peek the next token,
for example, for the expression testNum as number >= 0, after parsing testNum as number, the next cache will store a > character.
For the expression testNum >= 0, once testNum is processed, the next token to be queried is, as expected, >=.

In other words, a peak operation might have been performed in next_then_parse_ts_type, potentially resulting in the incorrect handling of subsequent tokens.

Possible solution:
At the end of the next_then_parse_ts_type function, discard the next cache and re-read the token.