You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Somehow, while writing real code, I stumbled upon this combination of constructs that seems to quickly produce huge types that hang or crash the compiler. I suggest that there should be some limit on type size at which the compiler gives up rather than potentially hanging/crashing, in the spirit of the limit of 100 on the depth of some existing operations in the checker.
Expected behavior: Compiler hits some safety limit on t3 and goes on to report the error on y.
Actual behavior: Compiler runs out of memory. In VS Code, the language service runs out of memory, crashes, restarts, runs out of memory, crashes, etc., and never reports the error on y. This is a poor user experience.
Related Issues:#24223. I originally thought my case was covered by #24223, but it isn't: #24223 is about a better algorithm to simplify a type that ends up being reasonable in size, while in my case, the fully simplified type is huge.
The text was updated successfully, but these errors were encountered:
It's problematic. This type isn't infinitely expanding in a way that triggers any of our depth checks, and doesn't really look to the checker like a problematic type in a way that we understand how to detect.
We discussed a bunch of ideas for how to deal with this but didn't come up with anything that wasn't likely to trigger false positives in working code. It's possible there's something... we just haven't found it yet.
Our only real answer at the moment is "don't write code like that" and we're just hoping for a better way to communicate that answer to the developer than hanging or crashing. Still a bug but we don't have an immediate answer.
Somehow, while writing real code, I stumbled upon this combination of constructs that seems to quickly produce huge types that hang or crash the compiler. I suggest that there should be some limit on type size at which the compiler gives up rather than potentially hanging/crashing, in the spirit of the limit of 100 on the depth of some existing operations in the checker.
TypeScript Version: master (2e89dbd)
Search Terms: keyof type parameter variable large type hang crash out of memory
Code
Expected behavior: Compiler hits some safety limit on
t3
and goes on to report the error ony
.Actual behavior: Compiler runs out of memory. In VS Code, the language service runs out of memory, crashes, restarts, runs out of memory, crashes, etc., and never reports the error on
y
. This is a poor user experience.Playground Link: may crash your browser
Related Issues: #24223. I originally thought my case was covered by #24223, but it isn't: #24223 is about a better algorithm to simplify a type that ends up being reasonable in size, while in my case, the fully simplified type is huge.
The text was updated successfully, but these errors were encountered: