x</x>/ fails to parse

[antimatter15]

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about it

⏯ Playground Link

Playground link with relevant code

💻 Code

x </x>/

🙁 Actual behavior

There is a parse error for a perfectly valid expression

Unexpected keyword or identifier.
Declaration or statement expected.
Unterminated regular expression literal.

🙂 Expected behavior

It should instead parse the expression as

x < /x>/

This is the behavior that is found in Babel and ESBuild.

[MartinJohns]

Why would you ever write code like this? Any practical example?

[Josh-Cena]

@MartinJohns A parser error is a parser error; it indicates a bug. If TS wants to remain a superset of JS it must parse all valid JS as JS. This seems like a lexing error; I'm not sure if the TS lexer follows the ES model, but the first / should definitely be consumed as InputElementRegExp because a < punctuator, whether as the start of a generic or as the less than operator, cannot be directly followed by a / punctuator.

[MartinJohns]

I'd argue the team has better things to do than to make sure some obscure code that's never really written works. Resources are finite.

[fatcerberus]

Given that the code parses successfully when adding a space after the <, the bug is likely caused by the ambiguity between JS and JSX interpretations of the same code, which wouldn't be unprecedented (this is not valid JSX because there's no opening <x> tag but error recovery in the parser muddies the waters).

I think there have been similar bugs in the past caused by parsing ambiguities that were deliberately not fixed (or at least not completely) due to design limitations in the parser, so I could definitely see "nobody would write this code" being the justification given for not fixing it. See for example #16241 (an extreme example where the JS and TS interpretations of the code are mutually exclusive) which looks like it did get fixed but took several years and a few attempts to do so.

[jcalz]

Reminds me of to #33639, which was considered "won't fix" even though it does technically mean that TS isn't exactly a superset of JS.

[Josh-Cena]

Originally I thought it was confused with instantiation expressions; but ambiguity with JSX seems harder to fix (albeit not impossible). However, #33639 was due to actual grammar ambiguity, but this one is simply a faulty lexer. (Easier said than done though; I don't know if it's trivial to fix, but should be fixable without fumbling with different ambiguous grammar extensions)

[RyanCavanaugh]

If someone can fix this without negative side effects, feel free to send a PR, but this is just a "You tried to break it on purpose and were successful" situation.

[fatcerberus]

this is just a "You tried to break it on purpose and were successful" situation

someone pick up that phone because I called it