union of tuples + spread tricks control flow analysis into thinking a reachable branch is not reachable

Bug Report

🔎 Search Terms

tuple spread control flow analysis type narrowing

🕗 Version & Regression Information

• This exists since at least 4.0.5 and is still present in the current 4.4.0-beta.
• 3.9.7 correctly fails to compile the snippet, but for what appear to be different reasons.

⏯ Playground Link

let current:
  | []
  | [string]
  | [string, string] = [];

const values = ['foo', 'bar', 'baz'];

for (const v of values) {
  if (current.length === 0) {
    current = ['first'];
  } else if (current.length === 1) {
    current; // -> correctly narrows type to [string]
    current = [...current, 'second'];
    current; // -> corrently infers type [string, string]

    // if, instead, we construct the tuple without spreads, the compiler correctly realizes the case below is reachable
    // current = [current[0], 'second'];
  } else {
    assertNever(current); // this should not compile; because this case is actually reachable
    console.log('here!'); // this line is hit, as expected
  }
}

function assertNever(condition: never) {

}

"use strict";
let current = [];
const values = ['foo', 'bar', 'baz'];
for (const v of values) {
    if (current.length === 0) {
        current = ['first'];
    }
    else if (current.length === 1) {
        current; // -> correctly narrows type to [string]
        current = [...current, 'second'];
        current; // -> corrently infers type [string, string]
        // if, instead, we construct the tuple without spreads, the compiler correctly realizes the case below is reachable
        // current = [current[0], 'second'];
    }
    else {
        assertNever(current); // this should not compile; because this case is actually reachable
        console.log('here!'); // this line is hit, as expected
    }
}
function assertNever(condition) {
}

{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "target": "ES2017",
    "jsx": "react",
    "module": "ESNext",
    "moduleResolution": "node"
  }
}

Playground Link: Provided

🙁 Actual behavior

The compiler erroneously claims the last case where current is length 2 cannot be reached (as represented by assertNever compiling without error) when current is reassigned with tuple spread. Furthermore, the compiler correctly identifies that current is a 2-tuple after the spread statement. The declared types also specify that current can be a 2-tuple, which leads me to believe it's the control flow analyzer getting fooled into narrowing the types too far.

The compiler correctly claims the last case can be reached when current is reassigned with each tuple member explicitly stated, which is equivalent to the spread in this case.

🙂 Expected behavior

The usage of spread/explicitly specifying tuple members should both fail to compile.

Beginne damit, das bereitgestellte Tuple-Spread-Beispiel mit den aufgeführten strikten Compileroptionen im TypeScript Playground zu reproduzieren. Verfolge die Kontrollflussanalyse rund um die Längenprüfungen und die erneute Zuweisung des Spreads. Als abgeschlossen gilt die Aufgabe, wenn sowohl Spread- als auch explizit konstruierte Tuple-Zuweisungen den erreichbaren assertNever-Zweig korrekt ablehnen.