-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Fixed accidental propagation of caching-related objectFlags
#52546
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
Conversation
@@ -16285,7 +16285,7 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker { | |||
let type = unionTypes.get(id); | |||
if (!type) { | |||
type = createType(TypeFlags.Union) as UnionType; | |||
type.objectFlags = objectFlags | getPropagatingFlagsOfTypes(types, /*excludeKinds*/ TypeFlags.Nullable); | |||
type.objectFlags = (objectFlags | getPropagatingFlagsOfTypes(types, /*excludeKinds*/ TypeFlags.Nullable)) & ~(ObjectFlags.IsUnknownLikeUnionComputed | ObjectFlags.IsUnknownLikeUnion); |
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 is a naive~ fix for the issue. I think that it would be best to remove those object flags and use a different mechanism to cache this information. This would prevent accidental propagation like this as this information should be unique to any given type.
I'm just not sure what's the preferred place to keep this sort of information. Let me know what is your preferred solution for this kind of caching and I will adjust the PR.
cc @ahejlsberg
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.
Thanks for tracking this down. The call to getUnionTypeFromSortedList
that causes the issue comes from filterType
. I'd suggest changing that call to
return getUnionTypeFromSortedList(filtered, (type as UnionType).objectFlags & (ObjectFlags.PrimitiveUnion | ObjectFlags.ContainsIntersections), /*aliasSymbol*/ undefined, /*aliasTypeArguments*/ undefined, newOrigin);
i.e. filter the flags there and leave getUnionTypeFromSortedList
alone. It might make sense to also change the parameter name from objectFlags
to precomputedObjectFlags
just to make its use clear. BTW, strictly speaking it isn't correct to reuse the old ObjectFlags.ContainsIntersections
in filterType
since the filtering operation may have removed all intersections. However, that flag is just an optimization hint, so no harm comes from propagating it.
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.
Regarding where to put the flags, I think they're fine where they are. We really don't want to introduce another property for this.
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.
You mention PrimitiveUnion
and ContainsIntersections
in the suggested change and in the following comment. I'm a little bit lost on how this relates to the reused IsUnknownLikeUnionComputed
and IsUnknownLikeUnion
that I have identified to be the root cause here.
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.
Those two flags are the only ones we want propagated into the new union type. All other flags should be zero. Including the ones you identified as the root cause.
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.
Ah, I see - that makes sense. I pushed out the requested change.
@typescript-bot test this |
Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at 3e34273. 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 3e34273. You can monitor the build here. |
Heya @jakebailey, I've started to run the diff-based user code test suite (tsserver) on this PR at 3e34273. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the perf test suite on this PR at 3e34273. 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 3e34273. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based top-repos suite (tsserver) on this PR at 3e34273. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the extended test suite on this PR at 3e34273. You can monitor the build here. |
@jakebailey Here are the results of running the user test suite comparing Everything looks good! |
1 similar comment
@jakebailey Here are the results of running the user test suite comparing Everything looks good! |
Heya @jakebailey, I've run the RWC suite on this PR - assuming you're on the TS core team, you can view the resulting diff here. |
@jakebailey Here they are:
CompilerComparison Report - main..52546
System
Hosts
Scenarios
TSServerComparison Report - main..52546
System
Hosts
Scenarios
StartupComparison Report - main..52546
System
Hosts
Scenarios
Developer Information: |
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
@jakebailey Here are the results of running the top-repos suite comparing Something interesting changed - please have a look. Detailsnocodb/nocodb
|
fixes #52475
cc @jakebailey @RyanCavanaugh