TypeScript Infer type predicates from function bodies using control flow analysis

Infer type predicates from function bodies using control flow analysis

Open danvk opened this issue 6 months ago • 54 comments

Fixes #16069 Fixes #38390 Fixes #10734 Fixes #50734

This PR uses the TypeScript's existing control flow analysis to infer type predicates for boolean-returning functions where appropriate. For example:

function isString(x: string | number) {
  return typeof x === 'string';
}

This currently has an inferred return type of boolean, but with this PR it becomes a type predicate:

I filed #16069 seven years ago (!) and thought it would be interesting to try and fix it. It turned out to be cleaner and simpler than I thought: only ~65 LOC in one new function. I think it's a nice win!

How this works

A function is a candidate for an inferred type guard if:

It does not have an explicit return type or type predicate.
Its inferred return type is boolean.
It has a single return statement and no implicit returns (this could potentially be relaxed later).
It does not mutate its parameter.

If so, then the function looks something like this:

function f(p: T, p2: T2, ...) {
  // ...
  return expr;
}

For each parameter, this PR determine what its flow type would be in each branch if the function looked like this instead:

function f(p: T, p2: T2, ...) {
  // ...
  if (expr) {
    p1;  // trueType
  } else {
    p2; // falseType
  }
}

The "else" branch is important because of the semantics of type predicates. If we have:

declare function isString(x: string | number): x is string;

then x is a string if this function returns true. But if it returns false then x must be a number. The exact condition is a little subtle because it depends on which negated types TypeScript is able to represent.

We can safely infer a type guard for a parameter if falseType = Exclude<T, trueType>.

Update: Actually a little more subtle even than that, see https://github.com/microsoft/TypeScript/pull/57465#issuecomment-1957867140

Wins

TypeScript is now able to infer type guards in many places where it's convenient, e.g. calls to filter:

const nums = [12, "foo", 23, "bar"].filter(x => typeof x === 'number');
//    ^? const nums: number[]

Since this piggybacks off of the existing flow type code, all forms of narrowing that TypeScript understands will work.

const foos = [new Foo(), new Bar(), new Foo(), new Bar()].filter(x => x instanceof Foo);
//    ^? const foos: Foo[]

There are a few other non-obvious wins:

Type guards now flow

const isString = (o: string | undefined): o is string => !!o;

// - (o: string | undefined) => boolean
// + (o: string | undefined) => o is string
const secondIsString = (o: string | undefined) => myGuard(o);

This is a gentle nudge away from truthiness footguns

We don't infer a type guard here if you check for truthiness, only if you check for non-nullishness:

const numsTruthy = [0, 1, 2, null, 3].filter(x => !!x);
//    ^? const numsTruthy: (number | null)[]
const numsNonNull = [0, 1, 2, null, 3].filter(x => x !== null);
//    ^? const numsNonNull: number[]

This is because of the false case: if the truthiness test returns false, then x could be 0. Until TypeScript can represent "numbers other than 0" or it has a way to return distinct type predicates for the true and false cases, there's nothing that can be inferred from the truthiness test here.

If you're working with object types, on the other hand, there is no footgun and a truthiness test will infer a predicate:

const datesTruthy = [new Date(), null, new Date(), null].filter(d => !!d);
//    ^? const datesTruthy: Date[]

This provides a tangible incentive to do non-null checks instead of truthiness checks in the cases where you should be doing that anyway, so I call this a win. Notably the example in the original issue tests for truthiness rather than non-null.

Type guards are more discoverable

Type predicates are an incredibly useful feature, but you'd never learn about them without reading the documentation or seeing one in a declaration file. Now you can discover them by inspecting symbols in your own code:

const isString = (x: unknown) => typeof x === 'string';
//     ^? const isString: (x: unknown) => x is string

This makes them feel like they're more a part of the language.

Inferred type guards in interfaces are checked

While this PR defers to explicit type predicates, it will check an inferred predicate in this case:

interface NumberInferrer {
  isNumber(x: number | string): x is number;
}
class Inferrer implements NumberInferrer {
  isNumber(x: number | string) {  // this is checked!!!
    return typeof x === 'number';
  }
}

Interesting cases

The identity function on booleans is, in theory, a type guard:

// boolId: (b: boolean): b is true?
const boolId = (b: boolean) => b;

This seems correct but not very useful: why not just test the boolean? I've specifically prohibited inferring type predicates on boolean parameters in this PR. If nothing else this significantly reduces the number of diffs in the baselines.

This is an interesting case:

function flakyIsString(x: string | number) {
  return typeof x === 'string' && Math.random() > 0.5;
}

If this returns true then x is a string. But if it returns false then x could still be a string. So it would not be valid to infer a type predicate in this case. This is why we have to check the falseType as well as the trueType. In general, combining conditions like this will prevent inference of a type predicate. It would be nice if there were a way for a function to return distinct type predicates for the true and false cases. This would make inference much more powerful. But that would be a bigger change.

I remember RyanC saying once that a function's return type shouldn't be a restatement of its implementation in the type system. In some cases this can feel like a move in that direction:

// function hasAB(x: unknown): x is object & Record<"a", unknown> & Record<"b", unknown>
function hasAB(x: unknown) {
  return x !== null && typeof x === 'object' && 'a' in x && 'b' in x;
}

Performance

We're doing additional work to infer type predicates, so performance is certainly a concern. I've run this with --extendedDiagnostics on a few of my own repos and didn't observe any significant changes. But TS Bot will have to be the judge here.

If there are performance concerns with the current implementation, there are a few options for reducing its scope:

Only run this on arrow functions
Only run this on contextually-typed arrow functions
Only run this on contextually-typed arrow functions where the context would use the type predicate (e.g. Array.prototype.filter).

Possible extensions

There are a few possible extensions of this that I've chosen to keep out of scope for this PR:

Check explicit type predicates. This PR defers to explicit type predicates, but you could imagine checking them instead. This would bring some type safety to user-defined type guards, which are currently no safer than type assertions.
Infer assertion functions. If you throw instead of returning a boolean, it should be possible to perform an analogous form of inference.
Infer type predicates on this. It's possible for a boolean-returning method to be a this predicate. This should be a straightforward extension of this PR.
Infer type predicates on functions that return something other than boolean. If dates is (Date|null)[], then dates.filter(d => d) is a fine way to filter the nulls. This PR makes you write dates.filter(d => !!d). I believe this is a limitation of type predicates in general, not of this PR.
Handle multiple returns. It should be possible to infer a type guard for this function, for example, but it would require more bookkeeping:

function isString(x: string | number) {
  if (typeof x === 'string') {
    return true;
  }
  return false;
}

Feb 21 '24 16:02 danvk

The TypeScript team hasn't accepted the linked issue #16069. If you can get it accepted, this PR will have a better chance of being reviewed.

Feb 21 '24 16:02 typescript-bot

@typescript-bot perf test this faster

Feb 21 '24 17:02 RyanCavanaugh

Heya @RyanCavanaugh, I've started to run the faster perf test suite on this PR at e2684f128975dac725f4af4f9e6f03d4e765cfbe. You can monitor the build here.

Update: The results are in!

Feb 21 '24 17:02 typescript-bot

I'm thinking this will break things like...

let isNumberable = (x: string | number) => typeof x === 'number';
isNumberable = x => !isNaN(parseInt(String(x)));

...as a function returning boolean is not assignable to a type predicate. This example is pretty contrived, but might be relevant for class inheritance (i.e. legal subclasses become illegal because the base class method now gets inferred as a typeguard).

Feb 21 '24 17:02 fatcerberus

@RyanCavanaugh The results of the perf run you requested are in!

Here they are:

tsc

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Angular - node (v18.15.0, x64)}
_{Memory used}	_{295,666k (± 0.01%)}	_{295,656k (± 0.01%)}	_~	_295,638k	_295,678k	_{p=0.630 n=6}
_{Parse Time}	_{2.66s (± 0.24%)}	_{2.66s (± 0.28%)}	_~	_2.65s	_2.67s	_{p=0.718 n=6}
_{Bind Time}	_{0.83s (± 0.99%)}	_{0.83s (± 1.18%)}	_~	_0.82s	_0.85s	_{p=0.383 n=6}
_{Check Time}	_{8.26s (± 0.31%)}	_{8.26s (± 0.52%)}	_~	_8.21s	_8.32s	_{p=0.872 n=6}
_{Emit Time}	_{7.11s (± 0.28%)}	_{7.12s (± 0.35%)}	_~	_7.08s	_7.15s	_{p=0.418 n=6}
_{Total Time}	_{18.86s (± 0.20%)}	_{18.87s (± 0.32%)}	_~	_18.82s	_18.96s	_{p=0.809 n=6}
_{Compiler-Unions - node (v18.15.0, x64)}
_{Memory used}	_{193,496k (± 1.54%)}	_{196,079k (± 1.56%)}	_~	_194,078k	_200,129k	_{p=0.128 n=6}
_{Parse Time}	_{1.36s (± 1.43%)}	_{1.36s (± 1.27%)}	_~	_1.33s	_1.38s	_{p=1.000 n=6}
_{Bind Time}	_{0.72s (± 0.00%)}	_{0.72s (± 0.00%)}	_~	_0.72s	_0.72s	_{p=1.000 n=6}
_{Check Time}	_{9.35s (± 0.47%)}	_{9.71s (± 0.26%)}	_{+0.36s (+ 3.89%)}	_9.69s	_9.76s	_{p=0.005 n=6}
_{Emit Time}	_{2.61s (± 0.47%)}	_{2.66s (± 0.21%)}	_{+0.04s (+ 1.53%)}	_2.65s	_2.66s	_{p=0.004 n=6}
_{Total Time}	_{14.05s (± 0.44%)}	_{14.45s (± 0.28%)}	_{+0.40s (+ 2.88%)}	_14.41s	_14.51s	_{p=0.005 n=6}
_{Monaco - node (v18.15.0, x64)}
_{Memory used}	_{347,475k (± 0.01%)}	_{347,539k (± 0.01%)}	_{+64k (+ 0.02%)}	_347,509k	_347,566k	_{p=0.005 n=6}
_{Parse Time}	_{2.48s (± 0.47%)}	_{2.48s (± 0.66%)}	_~	_2.46s	_2.50s	_{p=0.568 n=6}
_{Bind Time}	_{0.93s (± 0.44%)}	_{0.93s (± 0.00%)}	_~	_0.93s	_0.93s	_{p=0.405 n=6}
_{Check Time}	_{6.92s (± 0.27%)}	_{7.03s (± 0.37%)}	_{+0.11s (+ 1.54%)}	_7.00s	_7.07s	_{p=0.005 n=6}
_{Emit Time}	_{4.04s (± 0.34%)}	_{4.06s (± 0.43%)}	_~	_4.03s	_4.07s	_{p=0.161 n=6}
_{Total Time}	_{14.37s (± 0.12%)}	_{14.50s (± 0.16%)}	_{+0.13s (+ 0.88%)}	_14.47s	_14.53s	_{p=0.005 n=6}
_{TFS - node (v18.15.0, x64)}
_{Memory used}	_{302,868k (± 0.00%)}	_{302,836k (± 0.01%)}	_{-33k (- 0.01%)}	_302,784k	_302,864k	_{p=0.016 n=6}
_{Parse Time}	_{2.02s (± 0.70%)}	_{2.01s (± 0.58%)}	_~	_2.00s	_2.03s	_{p=0.161 n=6}
_{Bind Time}	_{1.00s (± 0.75%)}	_{1.01s (± 0.97%)}	_~	_1.00s	_1.02s	_{p=0.300 n=6}
_{Check Time}	_{6.35s (± 0.31%)}	_{6.34s (± 0.46%)}	_~	_6.29s	_6.37s	_{p=0.627 n=6}
_{Emit Time}	_{3.60s (± 0.29%)}	_{3.59s (± 0.43%)}	_~	_3.57s	_3.60s	_{p=0.797 n=6}
_{Total Time}	_{12.96s (± 0.18%)}	_{12.94s (± 0.23%)}	_~	_12.91s	_12.98s	_{p=0.222 n=6}
_{material-ui - node (v18.15.0, x64)}
_{Memory used}	_{511,290k (± 0.00%)}	_{511,308k (± 0.01%)}	_~	_511,283k	_511,383k	_{p=0.296 n=6}
_{Parse Time}	_{2.66s (± 0.46%)}	_{2.65s (± 0.75%)}	_~	_2.63s	_2.68s	_{p=0.557 n=6}
_{Bind Time}	_{1.00s (± 0.75%)}	_{0.99s (± 0.41%)}	_~	_0.99s	_1.00s	_{p=0.100 n=6}
_{Check Time}	_{17.30s (± 0.67%)}	_{17.32s (± 0.38%)}	_~	_17.19s	_17.36s	_{p=0.467 n=6}
_{Emit Time}	_{0.00s (± 0.00%)}	_{0.00s (± 0.00%)}	_~	_0.00s	_0.00s	_{p=1.000 n=6}
_{Total Time}	_{20.95s (± 0.52%)}	_{20.96s (± 0.32%)}	_~	_20.84s	_21.02s	_{p=0.377 n=6}
_{mui-docs - node (v18.15.0, x64)}
_{Memory used}	_{2,293,373k (± 0.00%)}	_{2,293,569k (± 0.00%)}	_{+196k (+ 0.01%)}	_2,293,468k	_2,293,639k	_{p=0.005 n=6}
_{Parse Time}	_{11.98s (± 0.92%)}	_{11.96s (± 0.69%)}	_~	_11.88s	_12.10s	_{p=0.871 n=6}
_{Bind Time}	_{2.65s (± 0.32%)}	_{2.64s (± 0.31%)}	_~	_2.63s	_2.65s	_{p=1.000 n=6}
_{Check Time}	_{102.52s (± 0.59%)}	_{101.24s (± 0.98%)}	_{-1.29s (- 1.25%)}	_99.81s	_102.66s	_{p=0.045 n=6}
_{Emit Time}	_{0.32s (± 1.28%)}	_{0.32s (± 1.60%)}	_~	_0.32s	_0.33s	_{p=0.114 n=6}
_{Total Time}	_{117.47s (± 0.51%)}	_{116.16s (± 0.89%)}	_{-1.31s (- 1.12%)}	_114.71s	_117.73s	_{p=0.037 n=6}
_{self-build-src - node (v18.15.0, x64)}
_{Memory used}	_{2,413,189k (± 0.02%)}	_{868,471k (± 0.02%)}	_{🟩-1,544,717k (-64.01%)}	_868,289k	_868,849k	_{p=0.005 n=6}
_{Parse Time}	_{4.90s (± 0.79%)}	_{5.50s (± 0.80%)}	_{🔻+0.60s (+12.27%)}	_5.45s	_5.57s	_{p=0.005 n=6}
_{Bind Time}	_{1.86s (± 0.92%)}	_{2.34s (± 0.36%)}	_{🔻+0.48s (+25.96%)}	_2.34s	_2.36s	_{p=0.004 n=6}
_{Check Time}	_{33.63s (± 0.43%)}	_{15.99s (± 0.39%)}	_{🟩-17.64s (-52.45%)}	_15.90s	_16.08s	_{p=0.005 n=6}
_{Emit Time}	_{2.68s (± 1.18%)}	_{0.03s (± 0.00%)}	_{🟩-2.65s (-98.88%)}	_0.03s	_0.03s	_{p=0.003 n=6}
_{Total Time}	_{43.08s (± 0.46%)}	_{23.88s (± 0.36%)}	_{🟩-19.20s (-44.57%)}	_23.80s	_24.04s	_{p=0.005 n=6}
_{self-compiler - node (v18.15.0, x64)}
_{Memory used}	_{418,962k (± 0.01%)}	_{414,976k (± 0.01%)}	_{-3,986k (- 0.95%)}	_414,938k	_415,064k	_{p=0.005 n=6}
_{Parse Time}	_{2.82s (± 2.15%)}	_{2.79s (± 3.64%)}	_~	_2.63s	_2.90s	_{p=0.256 n=6}
_{Bind Time}	_{1.10s (± 5.27%)}	_{1.12s (± 5.76%)}	_~	_1.08s	_1.21s	_{p=0.505 n=6}
_{Check Time}	_{15.19s (± 0.25%)}	_{15.44s (± 0.28%)}	_{+0.26s (+ 1.69%)}	_15.40s	_15.52s	_{p=0.005 n=6}
_{Emit Time}	_{1.13s (± 0.67%)}	_{0.02s (±18.82%)}	_{🟩-1.11s (-98.08%)}	_0.02s	_0.03s	_{p=0.003 n=6}
_{Total Time}	_{20.23s (± 0.19%)}	_{19.37s (± 0.27%)}	_{🟩-0.86s (- 4.27%)}	_19.31s	_19.45s	_{p=0.005 n=6}
_{vscode - node (v18.15.0, x64)}
_{Memory used}	_{2,847,216k (± 0.00%)}	_{2,847,890k (± 0.00%)}	_{+674k (+ 0.02%)}	_2,847,837k	_2,848,034k	_{p=0.005 n=6}
_{Parse Time}	_{10.78s (± 0.70%)}	_{10.74s (± 0.43%)}	_~	_10.70s	_10.83s	_{p=0.466 n=6}
_{Bind Time}	_{3.43s (± 0.29%)}	_{3.43s (± 0.62%)}	_~	_3.41s	_3.47s	_{p=0.402 n=6}
_{Check Time}	_{60.82s (± 0.46%)}	_{60.87s (± 0.37%)}	_~	_60.50s	_61.15s	_{p=0.873 n=6}
_{Emit Time}	_{16.90s (± 8.34%)}	_{16.27s (± 0.42%)}	_~	_16.16s	_16.36s	_{p=0.126 n=6}
_{Total Time}	_{91.93s (± 1.77%)}	_{91.31s (± 0.26%)}	_~	_90.93s	_91.58s	_{p=0.689 n=6}
_{webpack - node (v18.15.0, x64)}
_{Memory used}	_{395,919k (± 0.01%)}	_{396,017k (± 0.01%)}	_{+98k (+ 0.02%)}	_395,982k	_396,095k	_{p=0.005 n=6}
_{Parse Time}	_{3.12s (± 0.33%)}	_{3.13s (± 0.26%)}	_~	_3.12s	_3.14s	_{p=0.112 n=6}
_{Bind Time}	_{1.40s (± 0.58%)}	_{1.40s (± 0.37%)}	_~	_1.39s	_1.40s	_{p=0.752 n=6}
_{Check Time}	_{14.02s (± 0.35%)}	_{14.13s (± 0.24%)}	_{+0.10s (+ 0.74%)}	_14.08s	_14.18s	_{p=0.006 n=6}
_{Emit Time}	_{0.00s (± 0.00%)}	_{0.00s (± 0.00%)}	_~	_0.00s	_0.00s	_{p=1.000 n=6}
_{Total Time}	_{18.55s (± 0.27%)}	_{18.66s (± 0.23%)}	_{+0.11s (+ 0.62%)}	_18.60s	_18.72s	_{p=0.005 n=6}
_{xstate - node (v18.15.0, x64)}
_{Memory used}	_{513,455k (± 0.01%)}	_{513,468k (± 0.01%)}	_~	_513,404k	_513,507k	_{p=0.630 n=6}
_{Parse Time}	_{3.28s (± 0.37%)}	_{3.28s (± 0.19%)}	_~	_3.27s	_3.29s	_{p=0.403 n=6}
_{Bind Time}	_{1.54s (± 0.71%)}	_{1.54s (± 0.49%)}	_~	_1.53s	_1.55s	_{p=0.604 n=6}
_{Check Time}	_{2.87s (± 1.06%)}	_{2.85s (± 0.89%)}	_~	_2.82s	_2.89s	_{p=0.258 n=6}
_{Emit Time}	_{0.08s (± 4.99%)}	_{0.07s (± 0.00%)}	_{🟩-0.01s (-14.29%)}	_0.07s	_0.07s	_{p=0.002 n=6}
_{Total Time}	_{7.77s (± 0.45%)}	_{7.75s (± 0.40%)}	_~	_7.72s	_7.80s	_{p=0.334 n=6}

System info unknown

Hosts

node (v18.15.0, x64)

Scenarios

Angular - node (v18.15.0, x64)
Compiler-Unions - node (v18.15.0, x64)
Monaco - node (v18.15.0, x64)
TFS - node (v18.15.0, x64)
material-ui - node (v18.15.0, x64)
mui-docs - node (v18.15.0, x64)
self-build-src - node (v18.15.0, x64)
self-compiler - node (v18.15.0, x64)
vscode - node (v18.15.0, x64)
webpack - node (v18.15.0, x64)
xstate - node (v18.15.0, x64)

_Benchmark	_Name	_Iterations
_Current	_pr	₆
_Baseline	_baseline	₆

Developer Information:

Download Benchmarks

Feb 21 '24 17:02 typescript-bot

@fatcerberus true, but that can also cut the other way! See the deleted errors file for javascriptThisAssignmentInStaticBlock.ts.

Ryan pointed out on another issue that inferring a type guard breaks this sort of code as well https://github.com/microsoft/TypeScript/issues/38390#issuecomment-626019466

const a = [1, "foo", 2, "bar"].filter(x => typeof x === "string");
a.push(10);  // ok now, error with my PR

I assume the +3.89% check time on compiler-unions is bad? Is there any information on how I can run this locally and see what's going on?

The CI/self-check found a flaw in my criteria for inferring a type predicate. I actually need to be even more strict! I should not infer a type predicate for this function, even though Exclude<unknown, string> = unknown.

function isShortString(x: unknown) {
  return typeof x === 'string' && x.length < 10;
}

declare let str: string;
if (isShortString(str)) {
  str;  // string
} else {
  str;  // never
}

This is actually quite interesting. My approach has no way of distinguishing isShortString from:

function isString(x: unknown) {
  return typeof x === 'string';
}

They both have initType=unknown, trueType=string and falseType=unknown. It would be valid to infer a type guard for isShortString if it were only ever called with unknown types. But if you call it with something like string or string | number then you can see that one is a valid type guard while the other is not.

I need to think a little more about whether this is fixable or if it's a flaw with this whole approach.

Feb 21 '24 19:02 danvk

Ouch, that's tricky. If there's a && present in the condition then you have to make sure there are no additional non-narrowing checks (or that the additional checks didn't narrow something else instead)

Feb 21 '24 19:02 fatcerberus

@fatcerberus yeah, see updated comment. I need to think about it a little more, but this might be a deal-breaker for this approach.

Feb 21 '24 19:02 danvk

~~Negated types would be a great help here because the falseType would then be unknown & !string and the Exclude-based test would be sufficient.~~

nevermind, I'm dumb, you haven't ruled out all strings. ignore this

Feb 21 '24 19:02 fatcerberus

I'm feeling somewhat hopeful that this approach can be salvaged. Instead of requiring that:

falseType = Exclude<initType, trueType>

what we actually need is:

falseType = Exclude<T, trueType> \forall T <: initType

i.e. that this relationship holds for all subtypes of the declared type. I'm hoping that in practice this just means I need to check that the relationship holds for T=initType and T=trueType, i.e. add one more check.

Again, this would be much easier if a function could return a different type predicate for the true and false cases!

Feb 21 '24 20:02 danvk

That fix seemed to work and all tests pass, so we should be back in business. This is going to be a bit slower than the version that @typescript-bot tested earlier but I'm feeling more confident that it's correct.

Feb 21 '24 22:02 danvk

@typescript-bot test top200 @typescript-bot user test this @typescript-bot run dt

@typescript-bot perf test this faster @typescript-bot pack this

Feb 21 '24 22:02 jakebailey

Heya @jakebailey, I've started to run the tarball bundle task on this PR at d0e385e8c781be33d05aaeccc7dcb594d230c296. You can monitor the build here.

Feb 21 '24 22:02 typescript-bot

Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at d0e385e8c781be33d05aaeccc7dcb594d230c296. You can monitor the build here.

Update: The results are in!

Feb 21 '24 22:02 typescript-bot

Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at d0e385e8c781be33d05aaeccc7dcb594d230c296. You can monitor the build here.

Update: The results are in!

Feb 21 '24 22:02 typescript-bot

Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at d0e385e8c781be33d05aaeccc7dcb594d230c296. You can monitor the build here.

Update: The results are in!

Feb 21 '24 22:02 typescript-bot

Heya @jakebailey, I've started to run the faster perf test suite on this PR at d0e385e8c781be33d05aaeccc7dcb594d230c296. You can monitor the build here.

Update: The results are in!

Feb 21 '24 22:02 typescript-bot

Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/159974/artifacts?artifactName=tgz&fileId=6697AFDD16758083B1CD91AF9516D7A3DB7DCC2B13099E445566B57CD913996302&fileName=/typescript-5.5.0-insiders.20240221.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/[email protected]".;

Feb 21 '24 23:02 typescript-bot

@jakebailey Here are the results of running the user test suite comparing main and refs/pull/57465/merge:

There were infrastructure failures potentially unrelated to your change:

1 instance of "Package install failed"

Otherwise...

Something interesting changed - please have a look.

Details

follow-redirects

/mnt/ts_downloads/follow-redirects/tsconfig.json

[NEW] error TS2345: Argument of type 'string | String' is not assignable to parameter of type 'string'.
- /mnt/ts_downloads/follow-redirects/node_modules/follow-redirects/index.js(651,66)

puppeteer

packages/browsers/test/src/tsconfig.json

[MISSING] error TS2307: Cannot find module '@pptr/testserver' or its corresponding type declarations.
- packages/browsers/test/src/utils.ts#L13 in packages/browsers/test/src/tsconfig.json

pyright

/mnt/ts_downloads/pyright/build.sh

[NEW] error TS2339: Property 'nodeType' does not exist on type 'never'.
- /mnt/ts_downloads/pyright/pyright: ../pyright-internal/src/analyzer/testWalker.ts(78,47)
- /mnt/ts_downloads/pyright/pyright-internal: src/analyzer/testWalker.ts(78,47)
- /mnt/ts_downloads/pyright/vscode-pyright: ../pyright-internal/src/analyzer/testWalker.ts(78,47)

Feb 21 '24 23:02 typescript-bot

@jakebailey The results of the perf run you requested are in!

Here they are:

tsc

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Angular - node (v18.15.0, x64)}
_{Memory used}	_{295,649k (± 0.01%)}	_{295,682k (± 0.01%)}	_~	_295,641k	_295,730k	_{p=0.109 n=6}
_{Parse Time}	_{2.66s (± 0.15%)}	_{2.67s (± 0.21%)}	_~	_2.66s	_2.67s	_{p=0.282 n=6}
_{Bind Time}	_{0.83s (± 0.49%)}	_{0.84s (± 0.97%)}	_~	_0.83s	_0.85s	_{p=0.056 n=6}
_{Check Time}	_{8.26s (± 0.44%)}	_{8.28s (± 0.31%)}	_~	_8.26s	_8.33s	_{p=0.328 n=6}
_{Emit Time}	_{7.12s (± 0.09%)}	_{7.12s (± 0.25%)}	_~	_7.09s	_7.14s	_{p=0.737 n=6}
_{Total Time}	_{18.87s (± 0.19%)}	_{18.90s (± 0.19%)}	_~	_18.87s	_18.97s	_{p=0.291 n=6}
_{Compiler-Unions - node (v18.15.0, x64)}
_{Memory used}	_{191,595k (± 0.02%)}	_{195,558k (± 1.26%)}	_{+3,962k (+ 2.07%)}	_194,102k	_200,105k	_{p=0.005 n=6}
_{Parse Time}	_{1.36s (± 0.80%)}	_{1.35s (± 2.08%)}	_~	_1.32s	_1.39s	_{p=0.453 n=6}
_{Bind Time}	_{0.72s (± 0.00%)}	_{0.72s (± 0.00%)}	_~	_0.72s	_0.72s	_{p=1.000 n=6}
_{Check Time}	_{9.36s (± 0.46%)}	_{9.78s (± 0.80%)}	_{🔻+0.42s (+ 4.45%)}	_9.70s	_9.93s	_{p=0.005 n=6}
_{Emit Time}	_{2.62s (± 0.76%)}	_{2.65s (± 1.03%)}	_~	_2.62s	_2.69s	_{p=0.053 n=6}
_{Total Time}	_{14.07s (± 0.28%)}	_{14.50s (± 0.56%)}	_{+0.44s (+ 3.10%)}	_14.44s	_14.66s	_{p=0.005 n=6}
_{Monaco - node (v18.15.0, x64)}
_{Memory used}	_{347,461k (± 0.00%)}	_{347,527k (± 0.00%)}	_{+67k (+ 0.02%)}	_347,514k	_347,543k	_{p=0.005 n=6}
_{Parse Time}	_{2.48s (± 0.71%)}	_{2.48s (± 0.49%)}	_~	_2.46s	_2.49s	_{p=0.280 n=6}
_{Bind Time}	_{0.93s (± 0.44%)}	_{0.93s (± 0.44%)}	_~	_0.92s	_0.93s	_{p=1.000 n=6}
_{Check Time}	_{6.96s (± 0.66%)}	_{7.05s (± 0.59%)}	_{+0.09s (+ 1.32%)}	_7.00s	_7.11s	_{p=0.020 n=6}
_{Emit Time}	_{4.06s (± 0.46%)}	_{4.06s (± 0.53%)}	_~	_4.04s	_4.10s	_{p=0.683 n=6}
_{Total Time}	_{14.42s (± 0.40%)}	_{14.53s (± 0.20%)}	_{+0.11s (+ 0.76%)}	_14.48s	_14.56s	_{p=0.010 n=6}
_{TFS - node (v18.15.0, x64)}
_{Memory used}	_{302,868k (± 0.01%)}	_{302,848k (± 0.00%)}	_~	_302,837k	_302,857k	_{p=0.065 n=6}
_{Parse Time}	_{2.01s (± 1.33%)}	_{2.01s (± 0.96%)}	_~	_1.99s	_2.04s	_{p=0.934 n=6}
_{Bind Time}	_{1.00s (± 1.47%)}	_{1.01s (± 0.81%)}	_~	_1.00s	_1.02s	_{p=0.284 n=6}
_{Check Time}	_{6.36s (± 0.30%)}	_{6.33s (± 0.42%)}	_~	_6.29s	_6.37s	_{p=0.139 n=6}
_{Emit Time}	_{3.58s (± 0.33%)}	_{3.60s (± 0.27%)}	_{+0.02s (+ 0.56%)}	_3.58s	_3.61s	_{p=0.023 n=6}
_{Total Time}	_{12.95s (± 0.24%)}	_{12.95s (± 0.24%)}	_~	_12.90s	_12.99s	_{p=0.872 n=6}
_{material-ui - node (v18.15.0, x64)}
_{Memory used}	_{511,290k (± 0.00%)}	_{511,320k (± 0.01%)}	_~	_511,275k	_511,465k	_{p=0.689 n=6}
_{Parse Time}	_{2.65s (± 0.66%)}	_{2.65s (± 0.55%)}	_~	_2.63s	_2.67s	_{p=0.510 n=6}
_{Bind Time}	_{1.00s (± 0.55%)}	_{0.99s (± 1.11%)}	_~	_0.98s	_1.01s	_{p=0.227 n=6}
_{Check Time}	_{17.30s (± 0.43%)}	_{17.32s (± 0.37%)}	_~	_17.20s	_17.37s	_{p=0.629 n=6}
_{Emit Time}	_{0.00s (± 0.00%)}	_{0.00s (± 0.00%)}	_~	_0.00s	_0.00s	_{p=1.000 n=6}
_{Total Time}	_{20.94s (± 0.40%)}	_{20.96s (± 0.31%)}	_~	_20.84s	_21.03s	_{p=0.378 n=6}
_{mui-docs - node (v18.15.0, x64)}
_{Memory used}	_{2,293,496k (± 0.00%)}	_{2,293,665k (± 0.00%)}	_{+169k (+ 0.01%)}	_2,293,606k	_2,293,713k	_{p=0.005 n=6}
_{Parse Time}	_{11.97s (± 0.86%)}	_{11.96s (± 1.02%)}	_~	_11.85s	_12.17s	_{p=0.808 n=6}
_{Bind Time}	_{2.64s (± 0.50%)}	_{2.64s (± 0.15%)}	_~	_2.63s	_2.64s	_{p=0.446 n=6}
_{Check Time}	_{102.54s (± 0.61%)}	_{101.79s (± 0.85%)}	_~	_100.66s	_102.72s	_{p=0.109 n=6}
_{Emit Time}	_{0.32s (± 1.28%)}	_{0.32s (± 0.00%)}	_~	_0.32s	_0.32s	_{p=0.405 n=6}
_{Total Time}	_{117.47s (± 0.50%)}	_{116.70s (± 0.79%)}	_~	_115.57s	_117.84s	_{p=0.128 n=6}
_{self-build-src - node (v18.15.0, x64)}
_{Memory used}	_{2,413,290k (± 0.02%)}	_{2,415,358k (± 0.02%)}	_{+2,068k (+ 0.09%)}	_2,414,631k	_2,415,917k	_{p=0.005 n=6}
_{Parse Time}	_{4.92s (± 0.70%)}	_{4.91s (± 1.03%)}	_~	_4.82s	_4.97s	_{p=1.000 n=6}
_{Bind Time}	_{1.86s (± 0.74%)}	_{1.87s (± 0.76%)}	_~	_1.85s	_1.89s	_{p=0.101 n=6}
_{Check Time}	_{33.62s (± 0.34%)}	_{33.60s (± 0.45%)}	_~	_33.46s	_33.89s	_{p=0.471 n=6}
_{Emit Time}	_{2.72s (± 1.73%)}	_{2.69s (± 1.09%)}	_~	_2.66s	_2.73s	_{p=0.197 n=6}
_{Total Time}	_{43.14s (± 0.25%)}	_{43.10s (± 0.39%)}	_~	_42.93s	_43.38s	_{p=0.689 n=6}
_{self-compiler - node (v18.15.0, x64)}
_{Memory used}	_{418,986k (± 0.02%)}	_{419,551k (± 0.01%)}	_{+565k (+ 0.13%)}	_419,479k	_419,588k	_{p=0.005 n=6}
_{Parse Time}	_{2.85s (± 0.65%)}	_{2.80s (± 2.36%)}	_~	_2.67s	_2.85s	_{p=0.059 n=6}
_{Bind Time}	_{1.08s (± 0.51%)}	_{1.10s (± 5.36%)}	_~	_1.07s	_1.22s	_{p=0.476 n=6}
_{Check Time}	_{15.16s (± 0.35%)}	_{15.38s (± 0.25%)}	_{+0.22s (+ 1.44%)}	_15.31s	_15.42s	_{p=0.005 n=6}
_{Emit Time}	_{1.14s (± 1.02%)}	_{1.13s (± 1.12%)}	_~	_1.12s	_1.15s	_{p=0.140 n=6}
_{Total Time}	_{20.22s (± 0.19%)}	_{20.41s (± 0.21%)}	_{+0.19s (+ 0.95%)}	_20.34s	_20.45s	_{p=0.005 n=6}
_{vscode - node (v18.15.0, x64)}
_{Memory used}	_{2,847,902k (± 0.00%)}	_{2,848,336k (± 0.00%)}	_{+434k (+ 0.02%)}	_2,848,193k	_2,848,399k	_{p=0.005 n=6}
_{Parse Time}	_{10.74s (± 0.35%)}	_{10.76s (± 0.36%)}	_~	_10.71s	_10.81s	_{p=0.470 n=6}
_{Bind Time}	_{3.43s (± 0.40%)}	_{3.43s (± 0.24%)}	_~	_3.42s	_3.44s	_{p=0.933 n=6}
_{Check Time}	_{60.65s (± 0.90%)}	_{60.85s (± 0.19%)}	_~	_60.63s	_60.97s	_{p=0.092 n=6}
_{Emit Time}	_{16.31s (± 0.60%)}	_{16.28s (± 0.59%)}	_~	_16.17s	_16.42s	_{p=0.521 n=6}
_{Total Time}	_{91.13s (± 0.63%)}	_{91.32s (± 0.19%)}	_~	_91.06s	_91.54s	_{p=0.149 n=6}
_{webpack - node (v18.15.0, x64)}
_{Memory used}	_{395,939k (± 0.02%)}	_{396,031k (± 0.01%)}	_{+92k (+ 0.02%)}	_395,955k	_396,088k	_{p=0.020 n=6}
_{Parse Time}	_{3.11s (± 1.07%)}	_{3.13s (± 0.77%)}	_~	_3.10s	_3.16s	_{p=0.418 n=6}
_{Bind Time}	_{1.40s (± 0.54%)}	_{1.40s (± 0.84%)}	_~	_1.38s	_1.41s	_{p=0.933 n=6}
_{Check Time}	_{14.05s (± 0.40%)}	_{14.15s (± 0.19%)}	_{+0.10s (+ 0.72%)}	_14.12s	_14.20s	_{p=0.005 n=6}
_{Emit Time}	_{0.00s (± 0.00%)}	_{0.00s (± 0.00%)}	_~	_0.00s	_0.00s	_{p=1.000 n=6}
_{Total Time}	_{18.56s (± 0.36%)}	_{18.68s (± 0.25%)}	_{+0.12s (+ 0.64%)}	_18.62s	_18.76s	_{p=0.010 n=6}
_{xstate - node (v18.15.0, x64)}
_{Memory used}	_{513,416k (± 0.00%)}	_{513,441k (± 0.01%)}	_~	_513,364k	_513,501k	_{p=0.173 n=6}
_{Parse Time}	_{3.28s (± 0.26%)}	_{3.28s (± 0.16%)}	_~	_3.27s	_3.28s	_{p=0.533 n=6}
_{Bind Time}	_{1.54s (± 0.26%)}	_{1.54s (± 0.00%)}	_~	_1.54s	_1.54s	_{p=0.405 n=6}
_{Check Time}	_{2.88s (± 1.03%)}	_{2.84s (± 0.68%)}	_{-0.04s (- 1.45%)}	_2.82s	_2.87s	_{p=0.037 n=6}
_{Emit Time}	_{0.08s (± 4.99%)}	_{0.07s (± 5.69%)}	_{🟩-0.01s (-12.24%)}	_0.07s	_0.08s	_{p=0.008 n=6}
_{Total Time}	_{7.78s (± 0.38%)}	_{7.73s (± 0.24%)}	_{-0.05s (- 0.64%)}	_7.72s	_7.77s	_{p=0.013 n=6}

System info unknown

Hosts

node (v18.15.0, x64)

Scenarios

Angular - node (v18.15.0, x64)
Compiler-Unions - node (v18.15.0, x64)
Monaco - node (v18.15.0, x64)
TFS - node (v18.15.0, x64)
material-ui - node (v18.15.0, x64)
mui-docs - node (v18.15.0, x64)
self-build-src - node (v18.15.0, x64)
self-compiler - node (v18.15.0, x64)
vscode - node (v18.15.0, x64)
webpack - node (v18.15.0, x64)
xstate - node (v18.15.0, x64)

_Benchmark	_Name	_Iterations
_Current	_pr	₆
_Baseline	_baseline	₆

Developer Information:

Download Benchmarks

Feb 21 '24 23:02 typescript-bot

Hey @jakebailey, the results of running the DT tests are ready. There were interesting changes:

Branch only errors:

Package: lodash Error:

Error: 
/home/vsts/work/1/DefinitelyTyped/types/lodash/lodash-tests.ts
  1813:5  error  TypeScript@local expected type to be:
  string[]
got:
  "a"[]  @definitelytyped/expect
  1814:5  error  TypeScript@local expected type to be:
  string[]
got:
  "a"[]  @definitelytyped/expect

✖ 2 problems (2 errors, 0 warnings)

    at combineErrorsAndWarnings (/home/vsts/work/1/DefinitelyTyped/node_modules/.pnpm/@[email protected][email protected]/node_modules/@definitelytyped/dtslint/dist/index.js:194:28)
    at runTests (/home/vsts/work/1/DefinitelyTyped/node_modules/.pnpm/@[email protected][email protected]/node_modules/@definitelytyped/dtslint/dist/index.js:186:20)

You can check the log here.

Feb 21 '24 23:02 typescript-bot

@jakebailey Here are the results of running the top-repos suite comparing main and refs/pull/57465/merge:

Something interesting changed - please have a look.

Details

microsoft/vscode

3 of 54 projects failed to build with the old tsc and were ignored

src/tsconfig.json

error TS2345: Argument of type 'ChatTreeItem' is not assignable to parameter of type 'IChatResponseViewModel'.
- src/vs/workbench/contrib/chat/browser/chatWidget.ts#L240

src/tsconfig.tsec.json

error TS2345: Argument of type 'ChatTreeItem' is not assignable to parameter of type 'IChatResponseViewModel'.
- src/vs/workbench/contrib/chat/browser/chatWidget.ts#L240

prisma/prisma

80 of 115 projects failed to build with the old tsc and were ignored

packages/client/tsconfig.build.json

error TS2502: 'client' is referenced directly or indirectly in its own type annotation.
- packages/client/src/runtime/core/model/applyModelsAndClientExtensions.ts#L25
- packages/client/src/runtime/core/model/applyModelsAndClientExtensions.ts#L38
error TS2456: Type alias 'Client' circularly references itself.
- packages/client/src/runtime/getPrismaClient.ts#L314

Feb 22 '24 00:02 typescript-bot

Some errors reported by the bot could be seen as mistakes in the user's code. Why the result of a array, filtered to be an array of numbers, should be typed as anything else than an array of number ?

Building on top of the current approach, but increasing complexity :

A "read" type and a "write" type, for mutable objects.

The read type would represent the latest known type at a point in the control flow. In the case of the array filter, this would mean "this array can hold strings and numbers, but at this point, it only holds numbers". The write type is the type as we know it today.

This is clearly a whole new thing.

Bonus : at the end of the function, if the read type is the same as the write type, and the object is returned, then you can infer a type predicate. This part is out of the scope of your current PR, if I understood correctly.

Feb 22 '24 01:02 JesusTheHun

This idea is great! I seem to have come up with an implementation for fallback that doesn't require compilation support.

declare const notMatched: unique symbol
function isWhat<Input = unknown, T = never>(
  match: (input: Input, _: typeof notMatched) => T | typeof notMatched
): (
  (x: Input) => x is [T] extends [Input] ? Input & T : never
) {
  return ((x: any): boolean => {
    try {
      return match(x, notMatched) !== notMatched
    } catch (e) {
      if ([notMatched, void 0, null, TypeError].includes(e as any)) {
        return false
      }
      throw e
    }
  }) as any
}

const strs0 = [1, '1', true].filter(
//    ^? string[]
  isWhat((t, _) => typeof t === 'string' ? t : _)
)

const strs1 = [1, '1', true].filter(
//    ^? string[]
  isWhat(t => {
    if (typeof t === 'string') return t
    throw void 0
  })
)

playground

However, this requires an import. But we can simplify the usage of this function by using webpack or built-in global functions. If this pull request can be approved, it would be great. However, if it doesn't get approved, I think using this piece of code can still solve the current issue of the awkward usage of is.

Feb 22 '24 09:02 NWYLZW

@danvk So if I'm understanding correctly, this won't solve the OP of https://github.com/microsoft/TypeScript/issues/57457 because that just does .filter(value => value) and you already stated that

We don't infer a type guard here if you check for truthiness, only if you check for non-nullishness

However, I think this might solve https://github.com/microsoft/TypeScript/issues/57457#issuecomment-1959466319?

Feb 22 '24 13:02 fatcerberus

@danvk So if I'm understanding correctly, this won't solve the OP of #57457 because that just does .filter(value => value) and you already stated that

We don't infer a type guard here if you check for truthiness, only if you check for non-nullishness

@fatcerberus correct. That was a real plot twist when I realized that the code in the original issue shouldn't infer a type predicate after all. Inferring a type guard for that code would require some way for a type predicate to only apply to the true case, not the false case.

However, I think this might solve #57457 (comment)?

Yes, it solves that problem because this PR makes type predicates flow. playground

Feb 22 '24 14:02 danvk

I love this!

Feb 22 '24 18:02 DavidWeiss2

Really hope this gets merged!

Feb 22 '24 20:02 jacobshirley

Notes on the changes from the various test suites that @typescript-bot ran:

user test suite
- 1 instance of "Package install failed" -- is this referring to the puppeteer error? Is there any way to debug this?
- follow-redirects
  - ✅ This is a win. Here’s a minimal repro.
  - They have an isString function that checks for string | String. My PR correctly infers a predicate of x is string | String. Their code calls str1.endsWith(str2), where both are string | String thanks to the inferred type guard. TypeScript does not allow a String argument to endsWith. This works at runtime, though it seems to fine to prohibit it. This isn't detecting a bug but it does make type checking more consistent.
- puppeteer
  - 🐟 This was an existing infrastructure issue, see comment below.
- pyright
  - ✅ This is a win. Minimal repro.
  - There's a default case in a switch that references a property on an object that's (correctly) narrowed to never based on an inferred type guard. This just feels like improved type inference.
DefinitelyTyped
- lodash
  - ✅ This is a win.
  - This expectation on _.filter breaks because it's asserting string[] whereas the type is now (correctly) "a"[]. This is an increase in precision and a win for my PR. The test could be changed to $ExpectType string[] || "a"[] to match both before and after this PR.
top-repos
- microsoft/vscode
  - ~✅ This is a win. Minimal repro.~
  - ⚠️ Neutral See Ryan's comment below.
  - There's a type guard that's passed indirectly to filter: items.filter(i => isResponseVM(i)). The wrapper function prevented the predicate from being used, but with this PR TypeScript is not so easily fooled and the return type is narrowed which produces a type error.
  - The original code is fine, my change pushes it into a known nuisance involving indexOf. See my comment for the suggested workaround, which is to add a type annotation.
- prisma/prisma
  - 💥 This was a bug in my PR. Minimal repro, though I only get an error in VS Code, not in the playground.
  - My PR reports a circularity error whereas main does not. This seems to only happen when a constructor has a return statement. If my code is running on constructor functions, then that's bad news! I'll investigate.
  - Update My code was, indeed, running on constructor functions. But only constructor functions that had a single return statement that returned a value, i.e. very, very few constructors. The solution is to not run on constructors. Fix in https://github.com/microsoft/TypeScript/pull/57465/commits/ef2d4650473493b3f26a0b06dfa6fba1135b1dfe, see comment for an explanation.

There was one other error in the public Compiler-Unions PR https://github.com/microsoft/TypeScript/pull/54148 from code like this:

let capturedLeft = isSyntheticReference(left) ? left.expression : left;  // Expression
if (!isSimpleCopiableExpression(capturedLeft)) {  // detected as type guard
    capturedLeft = factory.createTempVariable(hoistVariableDeclaration);
}
let rightExpression = capturedLeft; // SimpleCopiableExpression <: Expression
// ...
rightExpression = factory.createAssignment(thisArg, rightExpression);  // Expression

isSimpleCopiableExpression becomes a type guard with this PR, which lets the type of capturedLeft narrow. This means that the inferred type of rightExpression goes from Expression to something narrower, which results in errors when you try to assign to it.

Since the intent is for rightExpression to be an Expression, the fix is to give it an explicit type annotation:

- let rightExpression = capturedLeft;
+ let rightExpression: Expression = capturedLeft;

Here's the fix: https://github.com/microsoft/TypeScript/commit/b54491c649fc3b243e0875ac042ec2138edd6982

Feb 22 '24 20:02 danvk

1 instance of "Package install failed" -- is this referring to the puppeteer error? Is there any way to debug this?

Ignore this; I just fixed it yesterday (hopefully), after I queued this PR's run.

Feb 22 '24 20:02 jakebailey

TypeScript TypeScript copied to clipboard

Infer type predicates from function bodies using control flow analysis

How this works

Wins

Type guards now flow

This is a gentle nudge away from truthiness footguns

Type guards are more discoverable

Inferred type guards in interfaces are checked

Interesting cases

Performance

Possible extensions

tsc

follow-redirects

/mnt/ts_downloads/follow-redirects/tsconfig.json

puppeteer

packages/browsers/test/src/tsconfig.json

pyright

/mnt/ts_downloads/pyright/build.sh

tsc

microsoft/vscode

src/tsconfig.json

src/tsconfig.tsec.json

prisma/prisma

packages/client/tsconfig.build.json

TypeScript
TypeScript copied to clipboard