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.
Reuse cached resolved signatures early #60208
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
Reuse cached resolved signatures early #60208
Changes from all commits
c40b6ca
cfb820c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
due to the circular nature of this example, the compiler goes into
resolveCall
for the same node twice in a nested mannergetResolvedSignature
ends up callingresolveAnonymousTypeMembers
fortypeof BaseItem
getResolvedSignature
again for the same node and alltypeof BaseItem
(those were set to an empty array) so the error is raised becausesignaturesRelatedTo
fails to determine that this source (typeof BaseItem
) has the required target signaturesgetCandidateForOverloadFailure
's result as thelinks.resolvedSignature
. That signature is(Base: new (...args: any[]) => any): any
(): BaseItem
asgetDefaultConstructSignatures
and that replaces the empty construct signatures preemptively set byresolveAnonymousTypeMembers
getResolvedSignature
call for this. When callinggetSignatureApplicabilityError
the compiler returns an error because it reuses cachedRelationComparisonResult.Failed
that was cached when relating the argument and parameter types in that inner callgetCandidateForOverloadFailure
again and tries to elaborate this error (again!).typeof BaseItem
changed "in-between". So the debug assert kicks finally kicks in and the compiler crashesThere 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.
Thanks a ton for this PR and the explanation! It makes the crash make much more sense to me now.
I will say some of these steps still seem to have a bit of concerning logic and seem to help explain something else weird I noted on my issue, namely that there doesn't have to be a "real" loop in the base type for you to get an error like
Argument of type 'typeof BaseItem' is not assignable to parameter of type 'new (...args: any[]) => any'.
Playground (make sure to make any edit to overcome the crash and view an 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.
tbh your example is somewhat convoluted to the point that I'm not sure if it should error or not. It's definitely outside of the "regular TS" territory 😅 so all I was after here was to fix the crash. Once this gets fixed you might want to raise a new issue about the circularity issue if you thing it shouldn't be reported