Add control flow complexity limiter #30931
Conversation
| const foo = function (this: any) { | ||
| var a, b, c, d, ab, bc, cd, da, blocks = this.blocks; | ||
| ~~~ | ||
| !!! error TS2563: The containing function or module body is too complex for control flow analysis. |
There was a problem hiding this comment.
Am I crazy for thinking that this input code doesn't actually look that complicated and that we're probably doing too much work somewhere? Like, this is all binary arithmetic - the result is quite literally always a number - I'm not even sure why control flow comes into play.
There was a problem hiding this comment.
eeeyyyeaaahhh; In reusing checkExpression verbatim within control flow, we're missing any fast-path-type-caluclation-only type savings we could get on statements like these. Without even looking at the operands we could pretty easily assume they're of type number. I mean, technically we can't straight up assume, thanks to bigints; but if a binary expression tree contains number literals the result is either an error or number, and likewise for bigint literals (and if both are in a binary expression tree then the result is definitely an error), and the error case should get flagged by the normal statement walk. We could probably get serious savings by skipping calculation of a ton of references in control flow with a simple syntactic walk like that, since it'd mean that for any binary arithmetic expression with numeric literals in it, we'd always be able to avoid following the reference chain.
There was a problem hiding this comment.
We could even flag such trees during binding (like we do for other subtree containment checks), so all we need to do is check a flag on the node during checking, hmmmmm...
There was a problem hiding this comment.
We're not using checkExpression verbatim, we're using getTypeOfExpression, the intent of which is to obtain the type of an expression with as little work as possible (with checkExpression being the fallback). We already optimize for non-generic call expressions with no overloads and assertion expressions, and we could certainly explore more optimizations.
The particular input code that led to this PR may indeed have many operations for which we can obtain a type just from looking at literals and operators, and, with some work, we might even be able to process the code without hitting the limiter. But of course someone could write the example to use named constants instead, and we'd be right back where we started. So, one way or the other, we need an overall work limiter.
The thing that could really make a difference is better caching of intermediate types. But knowing when it is safe to cache is tricky. In particular, code with back edges from loops is hard.
There was a problem hiding this comment.
This code contains zero loops (and zero generics and zero overloads), however, which is why this code, specifically, being problematic to us seems so odd to me. I definitely understand the desire to have some sort of graceful-failure-like hard cap on work done here, however I don't think this example is a good justification for it - the actual complexity of the given code is relatively low; it just currently triggers an unoptimized worst case (deep chains of apparently dependent statements with uncached checks on them). IMO, that itself merits some fixing, at which point this test won't be that useful for testing this limiter. :(
Although maybe this is also just a good example of why we should have a merge-able hierarchical cache; we call getTypeOfExpression with caching disabled in control flow because we don't know if we're in an inferential/contextual context or not, and caching control flow results in those contexts does bad things to the types we produce - if we could simply "always cache" and have call resolution merge/toss the cache layer as appropriate we'd probably not have this problem, at least in this case.
Really, the heart of it is that while I believe the limiter is probably needed for more graceful failure modes, I don't think it's really a "fix" - error'ing on completely valid input code should be a last resort for us, yeah? To be used when resources are truly stretched thin? This is just a poignant example of something we need to optimize, especially when the input code, to a human like myself, seems so simple.
There was a problem hiding this comment.
Per our discussion earlier, I've opened #30945 with an optimization that allows us to actually check this input code. With that, we'll have to find another example that actually triggers this limiter for the test to be useful (probably not hard - just strip out all the literals). ❤️
There was a problem hiding this comment.
#31003 is now a much more complete fix with minimal to no perf impact on non-degenerate cases. ❤️
|
Closing this since it is covered in #31003. |
This PR adds an additional control flow complexity limiter. We already have a limit of 2000 recursive invocations of
getTypeAtFlowNodeto avoid overflowing the call stack. With this PR we add a limit of 500000 invocations ofgetTypeAtFlowNodein total before we deem a function or module statement block too complex and disable control flow analysis along with reporting an error.Fixes #29926.