Nested destructuring over a mixed (non-tuple) array literal fails type-checking (`const [[m], n] = [[7], 8]`)

[nickna]

Summary

Nested array destructuring of a literal whose elements have different types is rejected by the type checker, in both declaration and assignment (#754) forms:

const [[m], n] = [[7], 8];        // Type Error: Index type '0' is not valid for indexing all members of union type 'number[] | number'.
let m2, n2; [[m2], n2] = [[7], 8]; // same

Uniform nesting works: const [[m], [k]] = [[7], [8]] (element type number[]). An explicit tuple annotation does not help (const [[m], n]: [number[], number] = [[7], 8] fails the same way).

Cause

[[7], 8] is inferred as (number[] | number)[] (array, union element) rather than the tuple [number[], number]. The __arrayDestructure normalization (#685) passes arrays through and indexes positionally, so src[0] is the union number[] | number, which is not indexable for the nested [m]. tsc uses the binding pattern as contextual type to infer the rhs as a tuple.

Fix shape

Propagate the destructuring pattern's arity/shape as a contextual type to the initializer so a mixed array literal infers as a tuple (SharpTS already has TryCheckArrayLiteralAsTuple for tuple-context inference — it just is not threaded through __arrayDestructure source checking). Pre-existing; surfaced again by #754.

[nickna]

Findings while attempting this (the partial fix was reverted — it changed behavior without fixing the headline case):

Inferring a non-spread array-literal __arrayDestructure source as a tuple of its element types (in TypeChecker.Calls.cs, the __arrayDestructure branch) does fix the leaf mixed case — const [a, b] = [1, "two"] then gives a: number, b: string (currently a false TS error: "Can only call functions" on a.toFixed()), and const [a,b,c] = [1,2] becomes a tuple-length error (matching tsc).

But it does not fix the headline nested case const [[m], n] = [[7], 8]. The inferred tuple flows correctly to the synthetic source temp in the leaf desugaring (const [x, y] = [[7], 8] then types x: number[]), yet in the nested desugaring the same temp ends up as the array (number[] | number)[], so src[0] is the non-indexable union again. The outer _destN = __arrayDestructure([[7], 8]) statement is identical in both desugarings, so the tuple is being lost/widened specifically along the nested path — not yet root-caused. An explicit const t: [number[], number] = ...; const [m] = t[0] works, confirming tuple-index-then-destructure is fine; the gap is getting the synthetic temp to carry the tuple type.

Proper fix is the one in the issue: thread the binding pattern's arity/shape as a contextual type to the source (and onto the synthesized temp), rather than relying on bare literal inference that the temp then widens. Shares its root cause with the object-property variant (destructuring a defaulted property over a source lacking it — filed separately).