Improve type inference for types like 'T | Promise<T>'

[Anders Hejlsberg (ahejlsberg)]

This PR improves type inference to union types that contain combinations of nested and naked type variables. Previously, we'd always give lower priority to inferences made to naked type variables in union types, but this produced sub-optimal results in some fairly basic scenarios (see #32434).

The improved algorithm for inferring from a single source type or a union of source types to a target union type is:

• First, infer from each source type to each target type that isn't a naked type parameter, tracking for each source whether any inferences are made from that type.
• Second, if there are source types from which no inferences were made in the first step, infer from a union of those source types to each naked type parameter in the target type. Give lower priority to these inferences only if the target contains more than one naked type parameter.

Some examples:

declarefunctionfoo<T>(x: T|Promise<T>): T;declareletx: false|Promise<true>;consty=foo(x);// booleandeclarefunctionbar<T>(x: T,y: string|T): T;constz=bar(1,2);// 1 | 2

Previously both of the examples above caused errors.

This PR also fixes an inconsistency we've long had.

declarefunctionbaz1<T>(x: T|string): T;declareconsts: string;constx1=baz1(s);// Was string, now unknowndeclarefunctionbaz2<T>(x: T|string|number): T;declareconstsn: string|number;constx2=baz2(sn);// Was never, now unknown

We now infer unknown for T in both cases above (because there is nothing left to infer from when the matching types are eliminated, and T has no constraint or default).

Fixes#32434.

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) run dt
TypeScript Bot (@typescript-bot) test this

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the extended test suite on this PR at c6b77fa. You can monitor the build here. It should now contribute to this PR's status checks.

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at c6b77fa. You can monitor the build here. It should now contribute to this PR's status checks.

[Anders Hejlsberg (ahejlsberg)]

Latest commit fixes an issue where strangely we infer nothing for T in

declarefunctionflatten<T>(array: ReadonlyArray<ReadonlyArray<T>>): T[];declareletnaa: number[][];letna=flatten(naa);

Before the commit, na would have type unknown[]. We currently limit inference between two types with the same symbol to a single level, which causes the issue. This is fixed by #31633, but meanwhile this commit is takes care of the issue for array types.

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) run dt
TypeScript Bot (@typescript-bot) test this

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the extended test suite on this PR at 8f02055. You can monitor the build here. It should now contribute to this PR's status checks.

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at 8f02055. You can monitor the build here. It should now contribute to this PR's status checks.

[Tim Suchanek (timsuchanek)]

Anders Hejlsberg (@ahejlsberg) you're probably very busy, but in case you find the time, it would be great if you could have a look at #32100 🙏

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) run dt
TypeScript Bot (@typescript-bot) test this

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the extended test suite on this PR at 623a172. You can monitor the build here. It should now contribute to this PR's status checks.

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at 623a172. You can monitor the build here. It should now contribute to this PR's status checks.

[Anders Hejlsberg (ahejlsberg)]

RWC tests look good. Only one change in vscode, an error that shouldn't be is now gone.

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) run dt

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at 2541a5d. You can monitor the build here. It should now contribute to this PR's status checks.

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) run dt

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at 9b2d9cd. You can monitor the build here. It should now contribute to this PR's status checks.

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) user test this

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized community code test suite on this PR at 203fd9f. You can monitor the build here. It should now contribute to this PR's status checks.

[TypeScript Bot (typescript-bot)]

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

[Anders Hejlsberg (ahejlsberg)]

Verified that user test suite differences are all preexisting conditions.

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) run dt

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at 5646856. You can monitor the build here. It should now contribute to this PR's status checks.

[Anders Hejlsberg (ahejlsberg)]

Two minor issues in DT tests are covered by DefinitelyTyped/DefinitelyTyped/pull/37057.

[Anders Hejlsberg (ahejlsberg)]

Merging this now. There are a few breaks in the RWC suites that I have reviewed with Ryan Cavanaugh (@RyanCavanaugh).

[Wesley Wigham (weswigham)]

I think this is significantly affecting vscode - there's no diff in the user PR because output is completely blocked by an issue during build (so the test outright fails with no diff) - microsoft/vscode#77835 should resolve that, as it's just a lingering affect of some old generator type definitions. Once that's in place, though, vscode has many new errors:

[Wesley Wigham (weswigham)]

Scratch that, it might be the node version bump itself that's breaking so much; or at least a fair part of it.