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.

Start by reproducing the provided tuple-spread example in the TypeScript Playground with the listed strict compiler options. Trace the control-flow analysis around the length checks and spread reassignment; done means both spread and explicitly constructed tuple assignments correctly reject the reachable assertNever branch.