TS 4.1 regression in type assertion of generic mapped type #41617

I tried to reduce the repro, but it reproduces only when all these present:

• conditional type that is being narrowed ReturnType<>
• generic mapped type that is constraints by itself T extends FunctionsObj<T>
• field accessed with generic type T[M]

TypeScript Bot (@typescript-bot) run repros

Heya Orta Therox (@orta), I've started to run the code sample repros for you. Here's the link to my best guess at the log.

👋 Hi, I'm the Repro bot. I can help narrow down and track compiler bugs across releases! This comment reflects the current state of the 2 repros in this issue running against the nightly TypeScript.

❌ Failed: -

• Property 'x' does not exist on type 'ReturnType<T[M]>'.

👍 Compiled

Here's the problem, but without control flow involved:

interface A { x: number }

declare function isA(a: unknown): a is A;

type FunctionsObj<T> = {
    [K in keyof T]: () => unknown
}

function g<
    T extends FunctionsObj<T>,
    M extends keyof T
>(a2: ReturnType<T[M]>, x: A) {
    x = a2; // shouldn't be allowed, but is
}

This is a bug in our subtyping rules, not control flow (which would undoubtedly be easier to fix).

TypeScript Bot (@typescript-bot) run repros

Heya Wesley Wigham (@weswigham), I've started to run the code sample repros for you. Here's the link to my best guess at the log.

Looks like the root cause is our change in 4.1 to isDeeplyNestedType - it is now erroneously flagging a target side of the comparison, which doesn't change, as "deeply nested". Since the source side of the relation goes through about 6 transforms with the target side remaining unchanged, both sides get flagged as "deeply nesting", resulting in a Maybe result which eventually allows the assignment. I think this can be remedied by having separate source/target stack depths, so we don't increase the target stack depth when we're only transforming the source for a comparison.