-
Notifications
You must be signed in to change notification settings - Fork 12.2k
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
Improve logic that chooses co- vs. contra-variant inferences #57909
base: main
Are you sure you want to change the base?
Conversation
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
@typescript-bot test top800 @typescript-bot perf test this faster |
src/compiler/checker.ts
Outdated
@@ -26465,10 +26465,10 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker { | |||
// and has inferences that would conflict. Otherwise, we prefer the contra-variant inference. | |||
const preferCovariantType = inferredCovariantType && (!inferredContravariantType || | |||
!(inferredCovariantType.flags & TypeFlags.Never) && | |||
some(inference.contraCandidates, t => isTypeSubtypeOf(inferredCovariantType, t)) && | |||
some(inference.contraCandidates, t => isTypeAssignableTo(inferredCovariantType, t)) && |
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.
If this is not the correct change then at the very least a test case should be proposed that shows how the isTypeSubtypeOf
is better.
When this check was originally introduced by @ahejlsberg here it was states that:
Furthermore, knowing that an error will result when the co-variant inference is not a subtype of the contra-variant inference, we now prefer the contra-variant inference because it is likely to have come from an explicit type annotation on a function. This improves our error reporting.
An alternative idea to fix this example would be to keep coAndContraRelationCheck
on inferenceContext
. From what I understand, the subtypeRelation
in this context is mainly used when dealing with multiple overloads - a single signature case uses assignableRelation
with chooseOverload
. So perhaps the used relation should determine what is being used here.
Hey @jakebailey, the results of running the DT tests are ready. There were interesting changes: Branch only errors:Package: react
Package: styled-theming
|
@jakebailey Here are the results of running the user tests comparing Something interesting changed - please have a look. Details
|
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@typescript-bot pack this |
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 could you rerun top800, dt and perf suites? a new playground would also be appreciated :) |
@typescript-bot test top800 @typescript-bot perf test this faster |
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 |
Hey @jakebailey, the results of running the DT tests are ready. There were interesting changes: Branch only errors:Package: styled-theming
|
@jakebailey Here are the results of running the user tests comparing Everything looks good! |
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@jakebailey Here are the results of running the top 800 repos comparing Everything looks good! |
The only reported error here is actually desired! See the comment here. I didn't look into this one before because of that and because it just involves multiple libraries with complicated type. I plan to reduce it to a test case now and add it here. EDIT:// From this initial repro: TS playground to this TS playground. It's pretty lengthy but I already have problems with removing from it just about anything. |
@typescript-bot test it |
Hey @jakebailey, the results of running the DT tests are ready. There were interesting changes: Branch only errors:Package: styled-theming
|
@jakebailey Here are the results of running the user tests comparing Everything looks good! |
Still just one error :p and I have commented on it already here |
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@jakebailey Here are the results of running the top 400 repos comparing Everything looks good! |
Indeed, just rechecking since this is old and also we have new perf benchmarks / stats. |
To review this it might be helpful to see how this evolved over time:
#27028
#46392
#52123
#52180
#54072
The reason why this inference fails today is that
isTypeSubtypeOf
leads torequireOptionalProperties === true
. This has such inferences:So the covariant inference lacks
body
property and thus it fails the check and the contravariant inference gets chosen at the end.fixes #57908
fixes #58468