Shortcircuit getTypeOfExpression for arithmetic operators when the type is trivially deducible by syntactically contained literals #30945
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #29926
In this PR, we use the transform flag aggregation walk to categorize a numeric arithmetic expression (operators which don't conditionally do stringy coercion like
+
) which contains number or bigint literals somewhere in its expression tree. We then use this in the checker to short-circuit expression type calculation for these trees, preventing us from needing to walk the flow control graph (or anything else, really) to determine types. Technically this information could be re-derived on demand in the checker; but by calculating it during the transform flags walk it's pretty much free.The primary change due to this is that in certain cases where previously we'd issue an error and make the expression the
errorType
(eg, when doing2n - false
), we now may return thebigint
type instead. I've also changedcheckBinaryLikeExpression
proper to match. There's no real reason to return theerrorType
over thebigintType
in these cases, since all it does is allow you to mask a followup number/bigint mixing bug with a prior one (really the type should benever
to be pedantic, since the expression will throw at runtime; but the downstream effects of that would be terrible during editing), and the error can only arise in these cases when at least one of the arguments is abigint
. Plus the error type effectively disables completions on the expression result, when the fix is almost always going to be "convert some number somewhere into a bigint to the expression evaluates without error"; so allowing completions to continue assuming such a fix seems reasonable to me.