Avoid getting single call signatures when parameter types are the same #58392
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
typescript-bot
added
the
For Uncommitted Bug
ahejlsberg
approved these changes
May 1, 2024
| @@ -20770,6 +20770,9 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker { | |||
| const sourceType = i === restIndex ? getRestOrAnyTypeAtPosition(source, i) : tryGetTypeAtPosition(source, i); | |||
| const targetType = i === restIndex ? getRestOrAnyTypeAtPosition(target, i) : tryGetTypeAtPosition(target, i); | |||
| if (sourceType && targetType) { | |||
There was a problem hiding this comment.
Change to sourceType && targetType && sourceType !== targetType and get rid of the conditional continue.
There was a problem hiding this comment.
done :) thanks for pointing out
Andarist
commented
May 1, 2024
src/compiler/checker.ts
Outdated
Comment on lines
20773
to
20775
| if (sourceType === targetType) { | ||
| continue; | ||
| } |
There was a problem hiding this comment.
I'm not super fond of this as a fix. It could be treated as a potential perf optimization~ - although I really doubt it would show anything in the perf runs, it's just an early bailout from this loop. It just happens to fix this particular circularity.
Similar bailouts are used in a couple of places in the code (even at the top of the containing function - compareSignaturesRelated).
Ideally, I'd just like to recognize this type as one without call signatures so it could be typechecked using regular rules. At first, I thought that this code could just be simplified for the scenarios with strictVariance - after all, if we already have strict variance on why do we need to special case anything here?
It turns out though that despite strict variance the callback parameters are still special - even if they are bivariant methods (!). This is somewhat surprising and I just learned about it today, while working on this but I guess it makes sense. Covariant type checking for callback parameters was introduced here. You can also see what changed when I tried to ignore this logic here
The problem arises on main because both getNonNullableType and getSingleCallSignature resolve properties of the type and both are called to learn if the parameter is a callback parameter.
In this specific case, I could also experiment with:
- avoiding transitive
resolveStructuredTypeMembersingetTypeFactsWorkerbased oncallerOnlyNeeds. if the caller only needs to learn if the type is nullable or not... we don't need to check if it's a function type to compute those facts - avoiding
resolveStructuredTypeMembersingetSingleSignaturewhenSignatureKind.Callis requested and the type's symbol has aSymbolFlags.Class. If the type is a class then it has a construct signature (and thusgetSingleCallSignaturecan't returntruein such a case) so the code could bail out early.
Some extra consideration for unions/intersections could be put into the above too.
There was a problem hiding this comment.
cc @ahejlsberg - i was elaborating on this down here when u asked the question about what exact code has caused this ;p
…call-signature-for-same-param-types
|
Any idea if this will land in 5.5? |
|
@typescript-bot test it |
|
Hey @jakebailey, the results of running the DT tests are ready. Everything looks the same! |
|
@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 400 repos comparing Everything looks good! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 #58391