-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Fixed cache key computation for tuple target types with partially named members #55695
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
Fixed cache key computation for tuple target types with partially named members #55695
Conversation
@@ -16392,10 +16392,9 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker { | |||
// [...X[]] is equivalent to just X[] | |||
return readonly ? globalReadonlyArrayType : globalArrayType; | |||
} | |||
const memberIds = mapDefined(namedMemberDeclarations, node => node ? getNodeId(node) : undefined); |
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 would previously compute the same cache key segment for [undefined, labelNode]
and [labelNode, undefined]
const key = map(elementFlags, f => f & ElementFlags.Required ? "#" : f & ElementFlags.Optional ? "?" : f & ElementFlags.Rest ? "." : "*").join() + | ||
(readonly ? "R" : "") + | ||
(memberIds.length ? "," + memberIds.join(",") : ""); | ||
(some(namedMemberDeclarations, node => !!node) ? "," + map(namedMemberDeclarations, node => node ? getNodeId(node) : "_").join(",") : ""); |
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.
Is there a reason to precheck rather than just doing the map and letting it give the empty string via returning nothing?
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.
Hmm, not rly - this only keeps the cache key shorter if there are no named members.
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.
Oh, I misread this and didn't notice that this was adding a conditional prefix. Just seemed less nice to double iterate but it's fine.
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.
I debugged this down in a moment between things so I didn't exactly give it an extended thought at that moment. It was previously added conditionally and I didn't spend a second thinking if this would still be needed after things change.
Since you called it out, I re-evaluated it and I think it is, indeed, redundant now. So I would be more than OK with dropping this. Unlabeled tuples are probably more common than labeled ones though but I doubt that the cache key size would impact perf in a significant way.
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.
All good, I'd just leave it as it's not a regression.
@typescript-bot test top100 |
Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at 01cb0ae. 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 01cb0ae. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at 01cb0ae. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the regular perf test suite on this PR at 01cb0ae. You can monitor the build here. Update: The results are in! |
@jakebailey Here are the results of running the user test suite comparing There were infrastructure failures potentially unrelated to your change:
Otherwise... Everything looks good! |
@jakebailey Here they are:
CompilerComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
StartupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
Hey @jakebailey, the results of running the DT tests are ready. |
Maybe this might be worth a backport given this can end up breaking the new feature in 5.2? @DanielRosenwasser |
fixes #55693