T extends (number | null) does not correctly narrow on null checks

[ghost]

TypeScript Version: v3.8.0-dev.20191212

Search Terms: extends null, type guards, inference

Expected behavior: I would expect that both test1 and test2 would behave identically and both type check.

Actual behavior: test2 does not correctly infer that value on the second half of the branch is number, and instead states that Number.isSafeInteger(number | null) is not possible, despite the fact that null was already checked for.

Related Issues: #29627 (closed)

Code

function test1(value: number | null): boolean {
    return value !== null && Number.isSafeInteger(value);
}

function test2<T extends number | null>(value: T): boolean {
    return value !== null && Number.isSafeInteger(value);
}

Output

"use strict";
function test1(value) {
    return value !== null && Number.isSafeInteger(value);
}
function test2(value) {
    return value !== null && Number.isSafeInteger(value);
}

Compiler Options

{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "declaration": true,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}

Playground Link: Provided

[jcalz]

Duplicate of #13995

[ghost]

Thank you for redirecting me to the existing bug! I tried to search for it but didn't seem to find it.

Will close this in favour of that one.

[RyanCavanaugh]

Closing again since this was somehow showing up in our "open issues" query