-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Improve constraints of nested conditional types applied to constrained type variables #59886
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Improve constraints of nested conditional types applied to constrained type variables #59886
Conversation
if (checkType.flags & TypeFlags.Any || distributiveConditionalConstraintIdentityStack.length !== 0 && !(inferredExtendsType.flags & TypeFlags.Never) && someType(getPermissiveInstantiation(inferredExtendsType), t => isTypeAssignableTo(t, getPermissiveInstantiation(checkType)))) { | ||
(extraTypes ??= []).push(instantiateType(getTypeFromTypeNode(root.node.trueType), combinedMapper || mapper)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is the core of the fix, previously only the first level of nested conditional type (in non tail-recursive scenarios) was including the instantiated true type in its extraTypes
(the reasoning behind that is outlined in the comment above and in the #56004 's description)
So now we are including it at all nested levels. In other words - previously the forConstraint
was only passed to the direct call of getConditionalTypeInstantiation
from getConstraintOfDistributiveConditionalType
but now this contextual~ information is used for all nested calls.
I've used a global variable to track this as it's not really feasible today to thread this through instantiateType
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it not feasible to thread forConstraint
through instantiateType
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conditional types could appear just at any deeper level of the instantiated type. It's doable to introduce some kind of InstantiationFlags
and pass it down to all called functions etc but it felt more complicated to attempt doing it. It would also be fairly easy to forget to pass that down somewhere.
function f9<S extends string>( | ||
x: IsMatchingStringInfiniteRecursionInFalseType2<S>, | ||
) { | ||
let t1: 1 = x; // Error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The error here changed from "Type instantiation is excessively deep and possibly infinite" to "Type '1 | 2' is not assignable to type '1'".
It feels fine here but perhaps it's not fine in general case and I should only return neverType
for recursive calls when the compiler is instantiating for the true type. This change comes from the fact that I'm letting the neverType
to be returned for any recursive call and this one comes from the false type.
@typescript-bot test it |
Hey @gabritto, the results of running the DT tests are ready. There were interesting changes: Branch only errors:Package: frida-gum
Package: ramda
Package: styled-components
|
@gabritto Here are the results of running the user tests with tsc comparing Everything looks good! |
@gabritto Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@gabritto Here are the results of running the top 400 repos with tsc comparing Something interesting changed - please have a look. Details
|
@Andarist seems like a bunch of things broke because some types became |
I have a hunch that this might be related to my comment here. I'll investigate and report back with the findings and new tests. |
fixes #59868
this is an extension of #56004