fix(es/parser): handle type assertions with non-callable types in binexp

[steffen-heil-secforge]

Description:

After type assertions (as) and satisfies expressions, the parser needs to determine whether a following < token is a comparison operator or the start of type parameters. This fix ensures that < is lexed as a comparison operator when the type cannot have type parameters.

Previously only primitive keyword types and literals were handled. This extends the logic to cover all non-callable type constructs:

• Primitive keyword types (number, string, boolean, etc.)
• Literal types (2, "x", true, 10n)
• this type
• Array types (number[], Array)
• Tuple types ([number, string])
• Union/intersection types (A | B, A & B)
• Type operators (keyof T, readonly T, unique symbol)
• Indexed access types (T[K])
• Conditional types (T extends U ? X : Y)
• Mapped types ({ [K in keyof T]: V })
• Type predicates (x is string)

This prevents parsing errors when these type assertions are followed by comparison operators.

Examples that now parse correctly:

• (i as number[]) < 5
• (i as [number, string]) < 5
• (i as number | string) < 5
• (i as keyof T) < 5

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: e18227b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

Binary Sizes

File	Size
swc.linux-x64-gnu.node	31M (31910408 bytes)

Commit: 64a931a

[codspeed-hq]

CodSpeed Performance Report

Merging #11251 will not alter performance

_{Comparing secforge:fix/type-assertion-disambiguation (e18227b) with main (d66dab5)¹}

Summary

✅ 138 untouched

Footnotes

1. No successful run was found on main (527c391) during the generation of this report, so d66dab5 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[CPunisher]

Could do please provide an example with https://play.swc.rs/ to show the parsing errors?

[steffen-heil-secforge]

Note, I will update the tests shortly

[steffen-heil-secforge]

The point is that there is no explicit bug in swc alone.
From the POV of swc this is just an optimization, because >= and <= are "merged" later in the parser code.
However, dprints typescript plugin uses swc internally and sees the unmerged tokens and then panics.
This patch prevents reading <= and >= (and others) incorrectly in the first place, maybe even making the merge login in the parser redundant. But I wanted to keep the change minimal.

Examples of dprint typescript failing because of this:
https://dprint.dev/playground/#code/JYAghgziB2CuC2AjApgJxAHgLwgKwG4BYAKCA/plugin/typescript
https://dprint.dev/playground/#code/JYAghgziAaA8CaA+EsC8ICsBuAsAKCA/plugin/typescript

[kdy1]

I don't think it's a bug of the ES parser. You added tests to a wrong place, meaning that it was already working