-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Tweak co/contra inference logic from #52123 #52180
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
@typescript-bot test this |
Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at 22cfe3a. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the extended test suite on this PR at 22cfe3a. You can monitor the build here. |
Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at 22cfe3a. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at 22cfe3a. You can monitor the build here. |
Heya @jakebailey, I've started to run the perf test suite on this PR at 22cfe3a. You can monitor the build here. |
Heya @jakebailey, I've started to run the tarball bundle task on this PR at 22cfe3a. You can monitor the build here. |
Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
@jakebailey Here are the results of running the user test suite comparing Everything looks good! |
Heya @jakebailey, I've run the RWC suite on this PR - assuming you're on the TS core team, you can view the resulting diff here. |
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
This PR turns out to only fix some of the examples in the linked issue.
|
Interesting situation... Co-variant inferences have no common supertype, so we pick the first in anticipation of an error being issued as a result. However, we could have succeeded by picking the contra-variant inference. Yup, we could do better here. I like your proposed fix. |
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.
Approved assuming performance is unaffected and tests are clean.
All user/top100/etc tests are clean; waiting on perf tests though since I have to merge a fix to main first to unblock it. |
@typescript-bot perf test this |
Heya @jakebailey, I've started to run the tarball bundle task on this PR at 60e15f3. You can monitor the build here. |
Heya @jakebailey, I've started to run the perf test suite on this PR at 60e15f3. You can monitor the build here. Update: The results are in! |
Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
Just tested this on #49929 and it works really well; even more cases I didn't notice are fixed, including inference I worked around with this: function castToNodeArray<T extends Node>(nodes: readonly T[]): NodeArray<T> {
return cast<NodeArray<T>, readonly T[]>(nodes, isNodeArray);
} I'll add these newly found examples as test cases here. |
Nah, nevermind; forgot that it was to do with the fact that I had to change cast's signature until #52123, so the above code was already not needed even before this PR, which is more about the union thing when there's ambiguity. |
@jakebailey Here they are:
CompilerComparison Report - main..52180
System
Hosts
Scenarios
TSServerComparison Report - main..52180
System
Hosts
Scenarios
StartupComparison Report - main..52180
System
Hosts
Scenarios
Developer Information: |
Perf looks the same (normal noise). Thanks for the review! |
Fixes #52179
In the case of
coAndContraVariantInferences4
, we end up withModifier
as the covariant type, but that isn't a subtype of bothModifier
andDecorator
, so it shouldn't be chosen; we instead wantNode
, the contravariant inference. But, if you flip things and test forDecorator
instead,Modifier
is still the covariant inference, but now it doesn't matchDecorator
, so we get the desired result,Node
.This tweaks the logic from #52123 by ensuring that even the current inference's candidates are checked against the inferred covariant type; this effectively removes the problematic choice for the covariant type produced via union ordering.
I'm not an expert; maybe the better win is to change
getCovariantInference
somehow. I just tried this and was surprised that it fixed all of my examples and broke no other test.