-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Improvements to strictSubtypeRelation
and getNarrowedType
#52282
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
strictSubtypeRelation
and getNarrowedType
@typescript-bot test this |
Heya @ahejlsberg, I've started to run the diff-based top-repos suite on this PR at 14985d4. You can monitor the build here. Update: The results are in! |
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at 14985d4. You can monitor the build here. |
Heya @ahejlsberg, I've started to run the diff-based user code test suite on this PR at 14985d4. You can monitor the build here. Update: The results are in! |
Heya @ahejlsberg, I've started to run the abridged perf test suite on this PR at 14985d4. You can monitor the build here. Update: The results are in! |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 14985d4. You can monitor the build here. |
@ahejlsberg Here are the results of running the user test suite comparing Everything looks good! |
Heya @ahejlsberg, I've run the RWC suite on this PR - assuming you're on the TS core team, you can view the resulting diff here. |
@ahejlsberg Here they are:Comparison Report - main..52282
System
Hosts
Scenarios
Developer Information: |
@ahejlsberg Here are the results of running the top-repos suite comparing Something interesting changed - please have a look. Details
|
@typescript-bot test this |
Heya @ahejlsberg, I've started to run the diff-based user code test suite on this PR at d7a80c4. You can monitor the build here. Update: The results are in! |
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at d7a80c4. You can monitor the build here. |
Heya @ahejlsberg, I've started to run the abridged perf test suite on this PR at d7a80c4. You can monitor the build here. Update: The results are in! |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at d7a80c4. You can monitor the build here. |
Heya @ahejlsberg, I've started to run the diff-based top-repos suite on this PR at d7a80c4. You can monitor the build here. Update: The results are in! |
@ahejlsberg Here are the results of running the user test suite comparing Everything looks good! |
@ahejlsberg Here they are:Comparison Report - main..52282
System
Hosts
Scenarios
Developer Information: |
# Conflicts: # src/compiler/checker.ts
@typescript-bot top200 |
@jakebailey This PR doesn't change anything with regards to #48840 and #52387. |
@typescript-bot test top200 |
@DanielRosenwasser I don't think there's such a thing as |
I guess I shouldn't have mentioned the PR as I think it drew the focus away from what I actually wanted checked. I meant that the issue thread (#48840) has some discussion as to what constitutes a top-function-type, which is changing in this PR via I'll just pack this PR and test it. @typescript-bot pack this |
Heya @jakebailey, I've started to run the tarball bundle task on this PR at e249498. You can monitor the build here. |
Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
Okay, the things I wanted to test appear to work fine, or at least have not changed behavior from 4.9 anyhow. |
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.
Would you be able to add tests that demonstrate the ordering among supertypey functions?
type A = (...args: any) => unknown;
type B = (...args: any[]) => unknown;
type C = (...args: never) => unknown;
type D = (...args: never[]) => unknown;
type E = () => unknown;
type FnTypes = A | B | C | D | E;
declare function isSomeFunc<T>(x: any): x is T;
function checkA(f: FnTypes) {
if (isSomeFunc<A>(f)) {
f
}
else {
f
}
f
}
function checkB(f: FnTypes) {
if (isSomeFunc<B>(f)) {
f
}
else {
f
}
f
}
function checkC(f: FnTypes) {
if (isSomeFunc<C>(f)) {
f
}
else {
f
}
f
}
function checkD(f: FnTypes) {
if (isSomeFunc<D>(f)) {
f
}
else {
f
}
f
}
function checkE(f: FnTypes) {
if (isSomeFunc<E>(f)) {
f
}
else {
f
}
f
}
@DanielRosenwasser More tests added. |
This PR fixes a number of inconsistencies related to the strict subtype relation and user defined type predicate narrowing. Specifically:
unknown
is related toany
butany
is not related tounknown
. Previously, the two were mutually related.S1
of the form(...args: A) => R
, whereA
isany
,any[]
,never
, ornever[]
, andR
isany
orunknown
, and a signatureS2
not of that form,S2
is related toS1
butS1
is not related toS2
. Previously, it was possible for such signatures to be mutually related.x = y
is has the same type asy
with any object literal freshness preserved. Previously, object literal freshness was stripped.The strict subtype relation primarily controls subtype reduction of union types. Subtype reduction occurs in control flow analysis and other situations that require determining a common supertype for multiple types. For example, given expressions
a
andb
of typeA
andB
, the element type of an array literal[a, b]
isA
ifB
is a subtype ofA
,B
ifA
is a subtype ofB
, orA | B
if neither is a subtype of the other. However, ifA
andB
are mutual subtypes, the type chosen may ultimately depend on declaration order, which isn't desired. The goal of the strict subtype relation is to impose a stable ordering by eliminating mutual subtypes, and the first three rules above further that goal.Fixes #50916.