Parser: exponential time and memory on nested a < (b = …) (failed type argument speculation is retried) #64763

🔎 Search Terms

"parser exponential time", "parser out of memory", "type arguments speculation", "instantiation expression parse slow"

🕗 Version & Regression Information

• This changed between versions 4.6.4 and 4.7.4 (likely Instantiation expressions #47607, "Instantiation expressions")

• Reproduces in 4.7.4, 5.9.3, 6.0.3, 7.0.2, and 7.1.0-dev.20261012.1 (typescript@next)

ts.createSourceFile time for the code below, with nesting depth n:

⏯ Playground Link

No response

💻 Code

The input is valid TypeScript with no errors; only the nesting depth matters. Here n = 14 (183 bytes):

declare let a: any, b: any, x: any;
x = a < (b = a < (b = a < (b = a < (b = a < (b = a < (b = a < (b = a < (b = a < (b = a < (b = a < (b = a < (b = a < (b = a < (b = 0))))))))))))));

🙁 Actual behavior

Parse time and memory grow about 3× with each nesting level. Numbers for tsc 7.0.2 (native); the file reports no errors:

typescript@next behaves the same. Malformed input grows even faster, about 5× per level. "a=b<c<(".repeat(11) is 77 bytes and takes 13.8 s and 21.6 GB.

A single small file can therefore make the compiler or the language server hang, and then run out of memory.

To be clear, I don't think people write such code by hand. Depth up to about 6 costs nothing measurable. I found this by fuzzing a tool built on a TS parser, not from a real codebase. It can still come from generated code, from code mid-edit in an editor, or from untrusted input to services that parse TypeScript.

🙂 Expected behavior

Parse time and memory stay roughly proportional to the input size.

Additional information about the issue

I'm aware of the security properties page and #64370. I'm reporting this anyway for three reasons:

• The trigger is small, valid code.
• Memory grows without bound.
• The fix mirrors an existing mechanism instead of adding a limit.