TypeScript Language Server False Positive Error Reporting

[DScheglov]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.87.0
• OS Version: Ubuntu 22.04

Steps to Reproduce:

1. Clone the project git clone https://github.com/DScheglov/res-test.git
2. Open the VS Code: code res-test
3. Install dependencies (in terminal): npm i
4. Open file ./src/index.ts

The following errors are shown:

These errors are false positive:

1. project is configured to use the same typescript compiler as a project. See .vscode/settings.json
2. project is compiled successfully via terminal: npx tsc (no errors)
3. errors are gone after TS Language Server is restared (Ctrl + Shift + P , TypeScript: Restart TS Server)
4. errors go back after any touch of the file (just add a space).

There is not such problem in WebStorm

(Sorry, I have to check)

Errors are not displayed in the TS Playground as well:
Playground

[RyanCavanaugh]

Minimized repro

export interface Result<T, E> {
  mapErr<F>(fn: (error: E) => F): Result<T, F>;
  [Symbol.iterator](): Generator<E, T>;
}

declare const okIfObject: (value: unknown) => Result<Record<string, unknown>, 'ERR_NOT_AN_OBJECT'>;
declare const okIfInt: (value: unknown) => Result<number, 'ERR_NOT_AN_INT'>;
export declare function Do2<T, E>(job: () => Generator<E, T>): void;

declare let value: unknown;
Do2(function* () {
  const object = yield* okIfObject(value).mapErr(
    error => 0
  );

  const age = yield* okIfInt(object.age).mapErr(
    error => 0
  );

  return { age };
});

[DScheglov]

@RyanCavanaugh

I've met similar error from eslint:

Shoud I register the bug in @typescript-eslint? Or there it will be fixed after this one?

[RyanCavanaugh]

I'm not sure how their rule works. If it depends on type information (looks like it does) then that error should go away after we fix this one.

[Andarist]

Analyzing Ryan's simplified repro the problem comes from encodedSemanticClassifications-full that is called before semantic diagnostics. It breaks the regular order of type checking since while collecting tokens it calls reclassifyByType on object's declaration. That reads its type and to do that it has to resolve the type of the yield expression. That is a function call that has to be inferred (speaking about .mapErr here) and that depends on the contextual type of the yield operand, that in turn requires the return type of the containing function to be computed which leads to computing type of the return expression and that depends on... object's type. That's how the circularity arises.

Failing test case for this situation:

/// <reference path='fourslash.ts'/>

// @strict: true
// @target: esnext
// @lib: esnext

//// export interface Result<T, E> {
////   mapErr<F>(fn: (error: E) => F): Result<T, F>;
////   [Symbol.iterator](): Generator<E, T>;
//// }
////
//// declare const okIfObject: (
////   value: unknown,
//// ) => Result<Record<string, unknown>, "ERR_NOT_AN_OBJECT">;
////
//// declare const okIfInt: (value: unknown) => Result<number, "ERR_NOT_AN_INT">;
////
//// export declare function Do2<T, E>(job: () => Generator<E, T>): void;
////
//// declare let value: unknown;
////
//// Do2(function* () {
////   const object = yield* okIfObject(value).mapErr((error) => 0);
////   const age = yield* okIfInt(object.age).mapErr((error) => 0);
////   return { age };
//// });

verify.encodedSemanticClassificationsLength('2020', 132);
verify.getSemanticDiagnostics([]);

[Andarist]

I spent some time on this to learn what the proper fix could be. I concluded that the only proper fix for this has to be about making the cycle resolution logic smarter - or for the "out of order" type resolution to alter its behavior somehow.

No extra flags passed down by the caller can fix this because the compiler doesn't always control the caller. For instance, I managed to somewhat improve the situation locally for the test case above but that didn't fix quick info problem at the very same location:

/// <reference path="fourslash.ts" />

// @strict: true
// @target: esnext
// @lib: esnext

//// export interface Result<T, E> {
////   mapErr<F>(fn: (error: E) => F): Result<T, F>;
////   [Symbol.iterator](): Generator<E, T>;
//// }
////
//// declare const okIfObject: (
////   value: unknown,
//// ) => Result<Record<string, unknown>, "ERR_NOT_AN_OBJECT">;
////
//// declare const okIfInt: (value: unknown) => Result<number, "ERR_NOT_AN_INT">;
////
//// export declare function Do2<T, E>(job: () => Generator<E, T>): void;
////
//// declare let value: unknown;
////
//// Do2(function* () {
////   const object/*1*/ = yield* okIfObject(value).mapErr((error) => 0);
////   const age = yield* okIfInt(object.age).mapErr((error) => 0);
////   return { age };
//// });

verify.quickInfoAt("1", "const object: Record<string, unknown>");

One of those calls checker.getTypeAtLocation while the other one calls checker.getTypeOfSymbolAtLocation. The problem with any attempt to fix this by passing extra information through callers/links/whatever is that it won't fix raw API calls like this: checker.getTypeOfSymbol(checker.getSymbolAtLocation(node)).

Perhaps there is a way to fix this by overriding resolutionStart at some moment conditionally but I don't know what exact moment that would be or what the condition guarding this should be 😉 A part of the idea could be that outer inference should always start before type resolution for a node nested in it under regular circumstances - maybe this fact can be leveraged to manipulate the resolution arrays or the resolutionStart variable

[RyanCavanaugh]

Additional repro noted at #57429 (comment)