-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Always discriminate contextual types by existing discriminant property #61097
base: main
Are you sure you want to change the base?
Always discriminate contextual types by existing discriminant property #61097
Conversation
@typescript-bot test it |
@jakebailey Here are the results of running the user tests with tsc comparing Everything looks good! |
Hey @jakebailey, the results of running the DT tests are ready. There were interesting changes: Branch only errors:Package: knockout
Package: react-dates
|
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@jakebailey Here are the results of running the top 400 repos with tsc comparing Something interesting changed - please have a look. Details
|
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.
Looks good
return false; | ||
} | ||
if (p.kind === SyntaxKind.PropertyAssignment) { | ||
return isPossiblyDiscriminantValue(p.initializer) && isDiscriminantProperty(contextualType, p.symbol.escapedName); |
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 feel like it's at least moderately concerning that this leaves the code with only one use of isPossiblyDiscriminantValue
; shouldn't it be the case that if isPossiblyDiscriminantValue
returns false, isDiscriminantProperty
should have also returned false?
The documentation for isPossiblyDiscriminantValue
implies that it's there to avoid circularities, so I'm surprised that it is a problem, and that we aren't somehow introducing circularities by not calling it anymore...
But even more surprisingly, if you just straight up delete isPossiblyDiscriminantValue
and its one use (so, make it so that it always returns true), no test fails.
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.
The documentation for isPossiblyDiscriminantValue implies that it's there to avoid circularities, so I'm surprised that it is a problem, and that we aren't somehow introducing circularities by not calling it anymore...
It may not be about circularities in the form of implicit any. One of the failures here is related to a code like this:
interface KnockoutObservable<T> {
(value: T): void;
}
interface KnockoutObservableStatic {
<T>(value: T): KnockoutObservable<T>;
}
interface KnockoutObservableArrayStatic {
<T>(value: T[]): KnockoutObservable<T>;
}
interface KnockoutStatic {
observable: KnockoutObservableStatic;
observableArray: KnockoutObservableArrayStatic;
}
declare var ko: KnockoutStatic;
ko.observableArray([
{ someProp: 1 },
{ someProp: 2, _destroy: "evals to true" },
{ someProp: 3 },
{ someProp: 4, _destroy: ko.observable(false) },
]);
At the moment, the inner ko.observable
has a resolving signature - that is temporarily set on it during inference. Requesting its type here changes that prematurely or smth like that. I haven't yet had time to investigate this further to see what I could do to mitigate this problem though.
fixes #58508
fixes #61095
I think the added
tests/cases/compiler/contextuallyTypedByDiscriminableUnion2.ts
test case tells it all (TS playground). Currently both property assignments that reference external values and shorthand property assignments are capable of narrowing this case but a property assignment with an "inline" initializer isn't.