GeezerVison

I should mention that with this PR, the check time for this repro drops from ~10s to about 0.4s.

TypeScript Bot (@typescript-bot) test this
TypeScript Bot (@typescript-bot) user test this inline
TypeScript Bot (@typescript-bot) run DT
TypeScript Bot (@typescript-bot) perf test this
TypeScript Bot (@typescript-bot) pack this
TypeScript Bot (@typescript-bot) all the things please

Heya Andrew Branch (@andrewbranch), I've started to run the inline community code test suite on this PR at 75ab347. You can monitor the build here.

Update: The results are in!

Heya Andrew Branch (@andrewbranch), I've started to run the extended test suite on this PR at 75ab347. You can monitor the build here.

Heya Andrew Branch (@andrewbranch), I've started to run the parallelized Definitely Typed test suite on this PR at 75ab347. You can monitor the build here.

Heya Andrew Branch (@andrewbranch), I've started to run the tarball bundle task on this PR at 75ab347. You can monitor the build here.

Heya Andrew Branch (@andrewbranch), I've started to run the perf test suite on this PR at 75ab347. You can monitor the build here.

Update: The results are in!

Hurray, I helped find something maybe useful!

Andrew Branch (@andrewbranch)
Great news! no new errors were found between main..refs/pull/46429/merge

If we're going to attempt to fix those, the fix really should be to have the conditional type construction logic decide to resolve the types instead of deferring them--but I think that has lower priority.

This is impossible in the general case - any condition with an infer has to be deferred so the infer can be instantiated with every possible input (since an infer result can't stand on its own) - if we don't reason about branch reachability in relationship checking, we can never handle conditional types that both filter and transform simultaneously like T extends () => infer I ? I : never. We knew that adding constraint checks on branch reachability would be expensive - but it's the typespace equivalent of doing control flow on genetics, which we also do wherever we can now.

Andrew Branch (@andrewbranch)
The results of the perf run you requested are in!

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

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the extended test suite on this PR at 75ab347. You can monitor the build here.

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized community code test suite on this PR at 75ab347. You can monitor the build here.

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the tarball bundle task on this PR at 75ab347. You can monitor the build here.

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at 75ab347. You can monitor the build here.

This is impossible in the general case

Agreed, and so be it. But it does seem like there are classes of cases where we ought to do better in conditional type construction. Both of the test cases that revert back to failing with this PR seem quite trivial--for example, checking if the check and extends types are identical, or if the extends type is a union that contains the check type, would cause us to resolve the conditional type to the true case.

Hey Anders Hejlsberg (@ahejlsberg), 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/113306/artifacts?artifactName=tgz&fileId=A263304AC84860808E706B7F5590B0AA3616661B50F7CE35CED050B21FF1B0C802&fileName=/typescript-4.5.0-insiders.20211019.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]".;

I think I can say with a high degree of certainty that whatever is going on in Andrew Casey (@amcasey)'s example is unrelated. I removed all of the logic having to do with assignability to conditional types (i.e. both #30639 and this PR), and the example still blows up with an instantiation depth error.

Please, no more plot twists, my heart can't handle it anymore.

Yeah, if the real world code is fast then I’m happy. Just wanted to make sure it was checked against the latest changes.

is there an example of a type that is no longer allowed as of this PR? the typescript 4.5 blog post mentions this PR

TypeScript no longer allows types to be assignable to conditional types that use infer, or that are distributive. Doing so previously often ended up causing major performance issues. For more information, see the specific change on GitHub.

but i can't seem to find a minimal example of what this means exactly

DetachHead good news (??), we found one: #47127 (comment)

DetachHead good news (??), we found one: #47127 (comment)

This is a BAD news for me. I deeply dependency this feature. Because of this breaking change, I cant update TypeScript, it's so bad for me, could you add a compiler option to support it as a migrate plan?