Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Ensure we don't overwrite computed CouldContainTypeVariables in new optimization #54507

Merged
merged 1 commit into from
Jun 5, 2023
Merged

Ensure we don't overwrite computed CouldContainTypeVariables in new optimization #54507

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions src/compiler/checker.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18800,8 +18800,12 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
// If none of the type arguments for the outer type parameters contain type variables, it follows
// that the instantiated type doesn't reference type variables.
if (result.flags & TypeFlags.ObjectFlagsType && !((result as ObjectFlagsType).objectFlags & ObjectFlags.CouldContainTypeVariablesComputed)) {
(result as ObjectFlagsType).objectFlags |= ObjectFlags.CouldContainTypeVariablesComputed |
(some(typeArguments, couldContainTypeVariables) ? ObjectFlags.CouldContainTypeVariables : 0);
const resultCouldContainTypeVariables = some(typeArguments, couldContainTypeVariables);
// The above check may have caused the result's objectFlags to update if the result is referenced via typeArguments.
if (!((result as ObjectFlagsType).objectFlags & ObjectFlags.CouldContainTypeVariablesComputed)) {
(result as ObjectFlagsType).objectFlags |= ObjectFlags.CouldContainTypeVariablesComputed |
(resultCouldContainTypeVariables ? ObjectFlags.CouldContainTypeVariables : 0);
}
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could also have been:

if ((result as ObjectFlagsType).objectFlags & ObjectFlags.CouldContainTypeVariablesComputed) {
    resultCouldContainTypeVariables &&= !!((result as ObjectFlagsType).objectFlags & ObjectFlags.CouldContainTypeVariables);
}
(result as ObjectFlagsType).objectFlags |= ObjectFlags.CouldContainTypeVariablesComputed |
    (resultCouldContainTypeVariables ? ObjectFlags.CouldContainTypeVariables : 0);

e.g., merge the result. But that felt wrong. But, my current fix doesn't feel all correct either. I'm going to investigate and see if there's a specific class of types that we're hitting.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also have a version which does something... clever. Grab typeCount before obtaining the result, and if its id is greater than the saved typeCount, then you know it's a new type and we can do the calculation. This stems from my thought that this optimization can only possibly be valid on newly created types.

But, that feels really unusual.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, with that latter solution (given guidance on how to determine what a "new type" is), we could simplify things a bit and just force calculate the value unconditionally, dropping the change in instantiateAnonymousType.

target.instantiations.set(id, result);
}
Expand Down