Getting type information for a node causes other nodes to return any for their type

[bradzacher]

Bug Report

🔎 Search Terms

Compiler API, unexpected any

🕗 Version & Regression Information

• This changed between versions 4.5.x and 4.6.x

This does not repro on 4.5.5, but repros against v4.6.2

⏯ Playground Link

Playground link with relevant code

💻 Code

export function getFutureVersion(baseVersion?: string): number[] {
  const toRelease: number[] = [];
  const baseRelease: number[] = [];
  return baseRelease.map((_, index) => {
    const toPart = toRelease[index] ?? 0;
    if (index < 1) {
      return toPart;
    }
    if (index === 1) {
      toPart;
      //  ^? any
      toPart.lol; // Property 'lol' does not exist on type 'number'.(2339)
      //  ^? any
      return toPart + (baseVersion === undefined ? 0 : 1); 
    }
    return 0;
  });
}

🙁 Actual behavior

You can see that in this repro intellisense reports the type of toPart as any even though TS also knows that it must be a number.

If I attempt to get the type of toPart:

window.sandbox.createTSProgram().then(program => {
  program.emit()
  const ast = program.getSourceFile('/input.tsx');
  console.log(
    program.getTypeChecker().getTypeAtLocation(
      ast.statements[0].body.statements[2].expression.arguments[0].body.statements[2].thenStatement.statements[0].expression,
    ),
  );
});

// -> {checker: {…}, flags: 1, id: 1, intrinsicName: 'any', objectFlags: 0}

Hazarding a guess intellisense and the ^? playground token both just use checker.getTypeAtLocation(node) to get the type (and checker.typeToString to print it).

If you switch the TS version to 4.5 then you'll see that the type is correctly printed as number and the above snippet logs:

{checker: {…}, flags: 8, id: 14, intrinsicName: 'number', objectFlags: 0}

🙂 Expected behavior

The 4.5 behaviour is correct - getTypeAtLocation should return a number type.

Related

typescript-eslint/typescript-eslint#4689

[gabritto]

This issue appears to be fixed in the 4.7 nightly: https://www.typescriptlang.org/play?noUncheckedIndexedAccess=true&useUnknownInCatchVariables=true&noFallthroughCasesInSwitch=true&noImplicitOverride=true&ts=4.7.0-dev.20220331#code/KYDwDg9gTgLgBAMwK4DsDGMCWEVwObAwBiSMSUwAasFAM7YoAUARgIa1U304D8AXHFowomFHgCUAlEgC2zGgG0AunADeAKDhw0OIXBgQASsAA2wdsCmz5UZXAC8cZQG5N23fDYdjZi1bmKKo4ubhRkULhewD7mHAB0MqxgjIwA+gA0cKIAJqDiDgB8am5aOih6BgAKrLAO+kamscAKOaAqPDxwAAyuWlqYCHCMrSBwADxwAIz5Gn19YeS4VTUwvX0AviVZg8MouaP2h1MzW1rLsGtzAPRXWgB6PKf11bBxJhAmznA3cJVQEGAaDAAJ5wADk7xMYLg2QgwFocBQEHgoEwehw+mBgPB0gCUDBcUYACYAMwkgCc4iePzgDyeCwizxWcAA1EMotQ6AwHEdULkEKJgNk4J0unABNMvltNnMGbgem51uJXOsgA
@bradzacher Do you think you can try and see if any of the original issues in typescript-eslint/typescript-eslint#4689 are also fixed in the nightly version?

[bradzacher]

@gabritto I tried reproing this in the playground against nightly and it's working fine now.
When I attempt the repro in tyepscript-eslint - it is still broken - TS still returns any.

I can't tell why the two behave differently.

I can provide a pretty minimal repro - https://github.com/bradzacher/typescript-eslint-issue-4689

Pointer to the code in the typescript-eslint codebase: https://github.com/typescript-eslint/typescript-eslint/blob/4c428c5840f113385dc3c91a06a781d2c1f7642d/packages/eslint-plugin/src/rules/restrict-plus-operands.ts#L128 (which just calls checker.getTypeAtLocation). For some reason this call returns an any type for toPart.

Playing around I can see that it only occurs if the identifier toPart is part of the return expression. For example this code correctly returns a number type for toPart:

export function getFutureVersion(baseVersion?: string) {
  const toRelease: number[] = [];
  const baseRelease: number[] = [];

  return baseRelease.map((_, index) => {
    const toPart = toRelease[index] ?? 0;
    toPart + 1; // correctly typed as number
  });
}

But changing the line to return toPart + 1 will trigger the bug.
Also adding return toPart after the line will also trigger the bug.

Narrowing down more - if we annotate the return of the map arrow function with number, then the bug is not triggered.

[RyanCavanaugh]

That code https://github.com/typescript-eslint/typescript-eslint/blob/4c428c5840f113385dc3c91a06a781d2c1f7642d/packages/type-utils/src/getConstrainedTypeAtLocation.ts#L6 also calls getBaseConstraint of nodeType and preferentially uses it -- that doesn't seem particularly correct. In this case map is a generic function call and we're in a return position, so there's potentially an effective constraint here.

[bradzacher]

@RyanCavanaugh whilst it is correct that the function does use getBaseConstraintOfType - in this case that call returns undefined - meaning we use the result of getTypeAtLocation, which returns an any type.

[RyanCavanaugh]

It'd be great to have a repro that doesn't depend on eslint.

[bradzacher]

@RyanCavanaugh this repro just depends on TS using 4.7.0-dev.20220418:
https://github.com/bradzacher/TS-48313-REPRO/tree/main

[JoshuaKGoldberg]

Debugging into the TypeScript type checker...

• In getTypeOfExpression, retrieving const cachedType = flowTypeCache[getNodeId(node)] does give a cached type of any.
• Object.keys(flowTypeCache) gives just the one, ['2766']
• cache[getNodeId(node)] = type; is called after the const type = checkExpression(node) in that same getTypeOfExpression function
• checkExpression -> checkExpressionWorker -> checkIdentifier -> getNarrowedTypeOfSymbol -> getTypeOfSymbol -> getTypeOfVariableOrParameterOrProperty -> getSymbolLinks
  • getSymbolId(symbol) is 11
• Putting a conditional breakpoint in getSymbolId for id === 11, the call stack goes up to getTypeOfVariableOrParameterOrProperty -> getTypeOfVariableOrParameterOrPropertyWorker -> getWidenedTypeForVariableLikeDeclaration
• The type given by getWidenedTypeForVariableLikeDeclaration is correctly a number, but later in getTypeOfVariableOfParameterOrPropertyWOrker, we return reportCircularityError(symbol) because !popTypeResolution() returned truthy

I'm not familiar with the type resolution stack, but this does seem fishy...