Fix stack overflow in relater's skipCaching path for recursive tuple types

[Copilot]

Recursive union types with fewer than 4 constituents (e.g., recursive tuple types with spreads) trigger unbounded recursion through the skipCaching path in isRelatedToEx, which bypasses recursiveTypeRelatedTo's depth protection entirely.

type Recur<T> = (
    T extends (unknown[]) ? {} : { [K in keyof T]?: Recur<T> }
) | [...Recur<T>[number][]];

function a<T>(l: Recur<T>[]): void {
    const x: Recur<T> | undefined = join(l); // goroutine stack overflow
}

The cycle is isRelatedToEx → unionOrIntersectionRelatedTo → eachTypeRelatedToType → isRelatedToEx with no depth check, consuming the full 1GB goroutine stack.

Changes

• relater.go: Add overallDepth counter to Relater, checked in the skipCaching branch with a limit of 100 (matching recursiveTypeRelatedTo). Sets overflow = true on exceeding, producing proper "Excessive stack depth" diagnostics instead of crashing.
• inference.go: Add depth counter to InferenceState with a limit of 200 in inferFromTypes as defense-in-depth against unbounded inferFromTypes → inferToMultipleTypes → inferFromTypes recursion (not protected by invokeOnce).
• Add compiler test case recursiveTupleTypeWithSpreadOverflow.ts.

---

📱 Kick off Copilot coding agent tasks wherever you are with GitHub Mobile, available on iOS and Android.

[RyanCavanaugh]

@ahejlsberg this seems like two fixes when only one is needed, but I'm not sure which is preferable (or maybe there's a third option)

[Copilot]

Pull request overview

Prevents stack overflows in the type-relater/inference recursion paths when caching is bypassed (e.g., recursive tuple types with spreads), ensuring the compiler reports “excessive depth” diagnostics instead of crashing.

Changes:

• Add an overallDepth guard in Relater.isRelatedToEx for the skipCaching path to stop unbounded recursion.
• Add a depth guard in inferFromTypes for defense-in-depth against recursive inference loops.
• Add a compiler regression test and baselines for recursive tuple type with spread overflow.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
testdata/tests/cases/compiler/recursiveTupleTypeWithSpreadOverflow.ts	Adds a repro case to ensure the compiler doesn’t crash on recursive tuple/spread types.
testdata/baselines/reference/compiler/recursiveTupleTypeWithSpreadOverflow.types	Captures expected type baseline output for the new test.
testdata/baselines/reference/compiler/recursiveTupleTypeWithSpreadOverflow.symbols	Captures expected symbol baseline output for the new test.
testdata/baselines/reference/compiler/recursiveTupleTypeWithSpreadOverflow.errors.txt	Captures expected error output (including excessive depth diagnostics).
internal/checker/relater.go	Introduces overallDepth limiting in skipCaching relatedness checks.
internal/checker/inference.go	Introduces a recursion depth limiter for inference to avoid unbounded recursion.

[Copilot]

The PR description says there is a depth limit of 200 in inferFromTypes, but this check happens before the increment, which effectively allows reaching a depth of 201 (the 201st call passes when n.depth == 200, increments to 201, and proceeds). If the intended hard cap is 200 active frames, increment first and then compare, or change the pre-check to >= 200 to align behavior with the stated limit.

[Copilot]

The overallDepth-- is manually paired with the increment; converting the decrement to a defer immediately after increment would make this depth accounting more robust against future edits (e.g., additional early returns added in this block) and maintain invariants more reliably. Also, consider replacing the magic number 100 with a named constant (ideally shared/derived from the existing recursion-depth limit used by recursiveTypeRelatedTo) to keep these limits consistent over time.