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.

Inizia riproducendo l’esempio fornito di spread di tuple in TypeScript Playground con le opzioni rigorose del compilatore indicate. Segui l’analisi del flusso di controllo intorno ai controlli della lunghezza e alla riassegnazione dello spread. Il lavoro è completato quando sia le assegnazioni con spread sia quelle di tuple costruite esplicitamente rifiutano correttamente il ramo assertNever raggiungibile.