Conditional type triggers "No error for last overload signature" exception

[Oblosys]

Bug Report

🔎 Search Terms

"No error for last overload signature" yields stale issue 35186, and a couple of more recent issues that got resolved: 48636, 37974. (The stale 35186 appears to be a different issue as it also occurs in versions before v5.0.4.)

🕗 Version & Regression Information

• This is a crash
• This changed between versions 4.9.5 and 5.0.4, and still occurs up to typescript@next.

⏯ Playground Link

Bug-workbench link with relevant code

💻 Code

// @filename: types.ts
export type ProductName = 'a' | 'b'

export type SubproductNameForProductName<P extends ProductName> = P extends unknown
 ? keyof EntitiesByProductName[P]
 : never

type EntitiesByProductName = {
 a: { a1: { value: 'a-a1' } }
 b: { b1: { value: 'b-b1' } }
}

export type DiscriminatedUnion<
 P extends ProductName = ProductName,
 E extends SubproductNameForProductName<P> = SubproductNameForProductName<P>,
> = P extends ProductName
 ? E extends SubproductNameForProductName<P>
 // ? E extends unknown // With unknown, the exception doesn't happen. 
 ? EntitiesByProductName[P][E]
 : never
 : never

// @filename: app.ts
import { SubproductNameForProductName, DiscriminatedUnion, ProductName } from './types'

export const bug = <P extends ProductName>() => {
 const subproducts: DiscriminatedUnion<P, SubproductNameForProductName<P>>[] = []
 subproducts.map((_: DiscriminatedUnion) => null)
}

🙁 Actual behavior

The compiler throws an exception:

/Users/martijn/git/Insify/insify-core/node_modules/typescript/lib/tsc.js:114747
 throw e;
 ^

Error: Debug Failure. No error for last overload signature
 at resolveCall (/Users/martijn/git/Insify/insify-core/node_modules/typescript/lib/tsc.js:70223:19)
 at resolveCallExpression (/Users/martijn/git/Insify/insify-core/node_modules/typescript/lib/tsc.js:70605:12)
 at resolveSignature (/Users/martijn/git/Insify/insify-core/node_modules/typescript/lib/tsc.js:70988:16)
 at getResolvedSignature (/Users/martijn/git/Insify/insify-core/node_modules/typescript/lib/tsc.js:71008:18)
 at checkCallExpression (/Users/martijn/git/Insify/insify-core/node_modules/typescript/lib/tsc.js:71120:23)
 at checkExpressionWorker (/Users/martijn/git/Insify/insify-core/node_modules/typescript/lib/tsc.js:74278:16)
 at checkExpression (/Users/martijn/git/Insify/insify-core/node_modules/typescript/lib/tsc.js:74189:32)
 at maybeCheckExpression (/Users/martijn/git/Insify/insify-core/node_modules/typescript/lib/tsc.js:73280:28)
 at BinaryExpressionStateMachine.onLeft (/Users/martijn/git/Insify/insify-core/node_modules/typescript/lib/tsc.js:73216:16)
 at Array.left (/Users/martijn/git/Insify/insify-core/node_modules/typescript/lib/tsc.js:25140:30)

🙂 Expected behavior

No compiler exception.

[jakebailey]

This crash bisects to #51771. Wesley Wigham (@weswigham)

[jakebailey]

Adding this after structuredTypeRelatedTo in recusiveTypeRelatedTo shows the problem:

if (entry !== undefined) {
 // If the previous entry and the result disagree, then something has gone wrong.
 Debug.assert(!!(entry & RelationComparisonResult.Succeeded) === (result !== Ternary.False), "Cached relationship does not match recalculated result");
}

We first check if two types are related during call resolution. We get a failed relation result the first time, and add the node to a list to process later if all fail, ignoring errors (since a later candidate may work). That happens in this example, but when we check a second time with errors enabled, we somehow decide that they are related and then don't report any errors, firing the debug assert later.

[Andarist]

When errors are not being reported relateVariances take a fast path here:
https://github.dev/microsoft/TypeScript/blob/cd23992100f8edd29ef9c29e29758008cdbeb8ec/src/compiler/checker.ts#L21954-L21956

Those variances fail there with:

Type 'ProductName' is not assignable to type 'P'.
 'ProductName' is assignable to the constraint of type 'P', but 'P' could be instantiated with a different subtype of constraint 'ProductName'.
 Type '"a"' is not assignable to type 'P'.
 '"a"' is assignable to the constraint of type 'P', but 'P' could be instantiated with a different subtype of constraint 'ProductName'.

When errors are reported though the compiler skips over that fast path and continues. It manages to successfully relate those types here with:

type DistributiveConstraint = (SubproductNameForProductName<P> extends "a1" ? { a1: { value: "a-a1"; }; }["a1" & SubproductNameForProductName<P>] : never) | (SubproductNameForProductName<P> extends "b1" ? { b1: { value: "b-b1"; }; }["b1" & SubproductNameForProductName<P>] : never)
type Target = DiscriminatedUnion

[jakebailey]

Thanks for looking; deleting reportErrors && "fixes" things, it seems (code from #29817). Not sure if it's slower or something though. I may post that as a PR just to see what happens.