Fix spread operator failing to distribute over union when type is inlined

[thromel]

Fixes #62812

Problem

When a union/intersection type like number | string appears in the true branch of a conditional type that has the same type as its check type, the type was incorrectly being narrowed with a substitution constraint. This caused issues when the union type was used as a type argument to a generic type.

For example:

type CrossProduct<Union, Counter extends unknown[]> =
    Counter extends [infer Zero, ...infer Rest]
    ? (Union extends infer Member
        ? [Member, ...CrossProduct<Union, Rest>]
        : never)
    : [];

type Depth1 = CrossProduct<number | string, [undefined]> // [string] | [number]

// This works correctly:
let test2: (number | string extends infer Union ? (Union extends unknown ? [Union, ...Depth1]: never) : never);
// Result: [string, string] | [number, number] | [string, number] | [number, string]

// But this was broken (inlined instead of aliased):
let test3: (number | string extends infer Union ? (Union extends unknown ? [Union, ...CrossProduct<number | string, [undefined]>]: never) : never);
// Expected: [string, string] | [number, number] | [string, number] | [number, string]
// Actual: [string, string] | [number, number]  (missing cross-product entries)

Root Cause

In getConditionalFlowTypeOfType, when processing a type node in the true branch of a conditional type, the function checks if the type matches the conditional's check type and creates a substitution type with the implied constraint.

The issue is that for structural types like number | string, different occurrences in the code all resolve to the same canonical type. So when CrossProduct<number | string, [undefined]> appeared inside the true branch of number | string extends infer Union ? ..., the type argument number | string was incorrectly being narrowed with the constraint Union even though it was a completely independent occurrence.

Fix

Added a check to skip this narrowing for union/intersection types that don't contain type variables:

const isStructuralTypeWithoutTypeVariables = !!(type.flags & TypeFlags.UnionOrIntersection) && !couldContainTypeVariables(type);
if (!isStructuralTypeWithoutTypeVariables && (covariant || type.flags & TypeFlags.TypeVariable) && ...) {

This ensures:

• Named types (interfaces, classes, type aliases) still get narrowed - different references to the same named type refer to the same entity
• Structural types (unions, intersections) without type variables are NOT narrowed - different occurrences are independent even if they structurally match

Test

Added tests/cases/conformance/types/spread/spreadTupleUnionDistribution.ts to verify the fix.

[thromel]

@microsoft-github-policy-service agree

[thromel]

@RyanCavanaugh

[typescript-bot]

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

• For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate