-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Fixed regression in reverse mapped type inference caused by cache leak #59232
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 regression in reverse mapped type inference caused by cache leak #59232
Conversation
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
This looks good but the tests are out of date, it seems! |
The fix is correct but causes test tests/cases/compiler/mappedTypeRecursiveInference.ts to stack overflow, which is the main problem. |
I think that my theory about 2 deep stacks being stacked on top of each other here might be correct. This
I captured this target and printed it after the stack was cleared and it succeeded. The result isn't pretty but it did "work": typeToString(target)
This isn't particularly useful display... so ye, definitely something could be done to optimize how this gets printed. That said, maybe making the type print lazy in diagnostics would be something worth exploring either way? If it's only a feasible idea it could improve the performance of some of those pathological cases as some of the created error messages end up being discarded. Interestingly, this doesn't print the same expansion of this type in the error message: // @strict: false
// @strictNullChecks: false
type Deep<T> = { [K in keyof T]: Deep<T[K]> };
const test: {
globalThis: Deep<typeof globalThis>;
} = { globalThis }; I don't know where the difference is between those 2. |
Adding my explanation of things to this:
Putting all of those things together means that this PR causes the test to stack overflow. |
…thub.com/Andarist/TypeScript into fix/reverse-mapped-inference-same-source
thanks @gabritto for fixing that printing issue ❤️ |
@typescript-bot test it |
Hey @gabritto, the results of running the DT tests are ready. Everything looks the same! |
@gabritto Here are the results of running the user tests with tsc comparing Everything looks good! |
@gabritto Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@gabritto Here are the results of running the top 400 repos with tsc comparing Everything looks good! |
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.
My review counts just for the parts of the PR I didn't write, but the original fix makes sense.
@typescript-bot cherry-pick to release-5.5 |
…e-5.5 (#59258) Co-authored-by: Mateusz Burzyński <mateuszburzynski@gmail.com>
This PR fixes regression from #57837 that was discovered here: reduxjs/redux-toolkit#4500
Unfortunately, it also conflicts with a PR that landed later on: #58318 . With this fix
tests/cases/compiler/mappedTypeRecursiveInference.ts
runs into:This is specifically caused by the newly introduced
reportRelationError
here: https://github.com/microsoft/TypeScript/pull/58318/files#diff-d9ab6589e714c71e657f601cf30ff51dfc607fc98419bf72e04f6b0fa92cc4b8R21710This gets called by
isPropertySymbolTypeRelated
in an already deep stack created by this infinitely expanding mapped type. Then that type (or its slice) gets converted into a string eagerly within this function bygetTypeNamesForErrorDisplay
and this recurses quite a bit too.I think that this isn't a new problem. Nothing is fundamentally wrong with the PR that added this
reportRelationError
. It's just that two big stacks call were accidentally "concatenated" in a way that they were not before.I'm looking for some guidance as to what could be a potential fix for this. My current best idea is to lazily convert types to strings when actually needed/when handing over to the TS Server as a final diagnostic. This would affect a bunch of places though and I don't want to follow that rabbit hole before getting initial thoughts from the team about this.
cc @gabritto