Fix parsing of call with type arguments after left shift (<<) - #64854

Fixes #37760

Problem

1 << alignof<T[]>() was misparsed, while the same code with >> parsed correctly:

function alignof<T>(): number { return 1; }
function bar<T>(): number { return 1 << alignof<T[]>(); }
// error TS2349: This expression is not callable. Type 'Number' has no call signatures.
// error TS1005: ',' expected.  (x2)
// emitted JS: function bar() { return 1(); }

When an expression is followed by <<, tryParseTypeArgumentsInExpression rescans it as < so that a generic function type can be the first type argument (f<<T>(x: T) => T>(g)). Here the speculative parse of <alignof<T[]> as a type argument list reports errors, but it still ends at > followed by (. So it was accepted, and the expression became the call 1<...>().

Implementation

In tryParseTypeArgumentsInExpression, if the speculative type argument list was started from a rescanned << and parsing it produced any diagnostics, rewind and return nil, so << is parsed as a left shift operator. A plain < keeps its existing behavior, and a valid f<<T>(x: T) => T>(...) still parses as type arguments.

Tests

Added tests/cases/compiler/leftShiftBeforeTypeArgumentCall.ts, covering <<, >>, >>>, <<=, >>=, >>>=, <, a parenthesized right operand, and a g<<U>(x: U) => U>(...) call that must still parse as type arguments. Before this change it produced 12 errors and emitted 1(); now it has no errors and emits 1 << alignof(). No other baselines changed. hereby test, test:all, lint, check:format, and generate (with a clean git diff) pass locally.

This change was written with the help of Claude Code; I have reviewed it and will handle review feedback myself.

🤖 Generated with Claude Code