typescript-go: Infinite recursion in inferFromTypes via getReturnTypeOfSignature (tsc 5.9 OK)
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 12/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- go, typescript
- Área
- compilers
Línea de trabajo
Start from the stack in the issue: getReturnTypeOfSignature in the checker, then inferFromTypes and inferFromTypeArguments in inference.go (around lines 89-98 and 311), and fillMissingTypeArguments in checker.go. Reproduce with the linked repo (npx oxlint --type-aware src) and api-probe.cjs. Done means the recursion terminates, ideally by hitting an instantiation or depth limit, with tsc and tsgo agreeing on the result.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
🔎 Search Terms
Infinite Recursion, getReturnTypeOfSignature, IsEqual
🕗 Version & Regression Information
Versions
- typescript-go as bundled in
[email protected](also 0.24.0, 0.25.0);@typescript/[email protected]fortsgo --noEmit - typescript 5.9.3 for comparison
- macOS arm64
⏯ Playground Link
https://github.com/jandolezal71/typescript-go-issue-64701-repro
💻 Code
Repro
https://github.com/jandolezal71/typescript-go-issue-64701-repro
npm i
npx tsc --noEmit # ok, ~1 s
npx oxlint --type-aware src # never finishes
package.json devDependencies: [email protected], [email protected], [email protected], [email protected], [email protected]
.oxlintrc.json
{"plugins":["typescript"],"categories":{"correctness":"off"},"rules":{"typescript/no-misused-promises":"error"}}
tsconfig.json
{"compilerOptions":{"target":"ES2022","module":"ESNext","moduleResolution":"Bundler","strict":true,"noEmit":true,"skipLibCheck":true},"include":["src"]}
src/repro.spec.ts
import type { Asyncify, IsEqual, PartialDeep } from 'type-fest';
import { expect, vi } from 'vitest';
type Fn = (...args: any) => any;
type FirstOverload<TFn extends Fn> = (...args: Parameters<TFn>) => ReturnType<TFn>;
type NextOverload<TFn extends Fn, TStack extends Fn> = (...args: Parameters<TStack & TFn>) => ReturnType<TStack & TFn>;
type SafeAsyncify<TFn extends Fn> = ReturnType<TFn> extends Promise<unknown> ? TFn : Asyncify<TFn>;
// Collects all overloads of TFn; recursion stops once the next overload equals the previous one.
type PromisifyInner<TFn extends Fn, TAcc extends Fn, TStack extends Fn, TPrevious extends Fn, TCurrent extends Fn = NextOverload<TFn, TStack>> =
IsEqual<TCurrent, TPrevious> extends true ? TAcc : PromisifyInner<TFn, TAcc & SafeAsyncify<TCurrent>, TCurrent & TStack, TCurrent>;
type Promisify<TFn extends Fn, TFirst extends Fn = FirstOverload<TFn>> = PromisifyInner<TFn, SafeAsyncify<TFirst>, TFirst, TFirst>;
type IfThenElse<C, T, F> = false extends C ? F : T;
type OwnProperties<T> = { [K in keyof T]: T[K] };
type AddOptionalRequestOptions<TFn> = TFn extends (...args: [...infer TArgs]) => infer TReturn
? ((...args: [...TArgs, requestOptions?: { timeout?: number }]) => TReturn) & TFn
: TFn;
type PromisifyProcedureTree<T> = T extends Fn
? ReturnType<T> extends Promise<unknown>
? AddOptionalRequestOptions<T>
: IfThenElse<
keyof OwnProperties<T> extends never ? true : false,
AddOptionalRequestOptions<Promisify<T>>,
AddOptionalRequestOptions<Promisify<T>> & PromisifyProcedureTree<OwnProperties<T>>
>
: T extends Record<string, unknown>
? { readonly [K in keyof T]: PromisifyProcedureTree<T[K]> }
: T;
type ProtocolValue = null | string | number | boolean | Date | readonly ProtocolValue[] | { readonly [key: string]: ProtocolValue };
type ProcedureTree<TProtocolValue> = {
readonly [key: string | number]:
| ProcedureTree<TProtocolValue>
| ((...args: never[]) => void | PartialDeep<TProtocolValue> | Promise<void | PartialDeep<TProtocolValue>>);
};
declare class Client<TTree> {
get call(): PromisifyProcedureTree<TTree>;
}
declare function createHandler<TTree extends ProcedureTree<ProtocolValue>>(): (client: Client<TTree>) => void;
expect(vi.mocked(createHandler)).toHaveBeenCalledTimes(1);
tsc API comparison (node api-probe.cjs, finishes in ~80 ms)
const ts = require('typescript');
const cfg = ts.getParsedCommandLineOfConfigFile('./tsconfig.json', {}, { ...ts.sys, onUnRecoverableConfigFileDiagnostic() {} });
const program = ts.createProgram(cfg.fileNames, cfg.options);
const checker = program.getTypeChecker();
const sf = program.getSourceFile('./src/repro.spec.ts');
let n = 0;
const t0 = Date.now();
(function visit(node) {
if (ts.isExpression(node)) {
const type = checker.getTypeAtLocation(node);
for (const part of type.isUnion() ? type.types : [type]) {
for (const sig of part.getCallSignatures()) { checker.getReturnTypeOfSignature(sig); n++; }
for (const prop of part.getProperties()) {
const pt = checker.getTypeOfSymbolAtLocation(prop, node);
for (const sig of pt.getCallSignatures()) { checker.getReturnTypeOfSignature(sig); n++; }
}
}
}
ts.forEachChild(node, visit);
})(sf);
console.log(`tsc ${ts.version} API: ${n} return types resolved in ${Date.now() - t0} ms`);
🙁 Actual behavior
Checker never terminates in getReturnTypeOfSignature (inference recursion) on overload-walking type; tsc 5.9 resolves it in milliseconds
What happens
checker.getReturnTypeOfSignaturenever returns: 100 % CPU indefinitely (observed >20 min).- It is reached through the type-aware linter tsgolint, rule
no-misused-promises(alsostrict-void-return). The rule only asks for the return type of a call signature. tsgo --noEmiton the same project finishes in ~1 s with no errors, because the plain check never requests this return type.
tsc 5.9.3 does not hang on the same requests
Through the TS API, I requested the return type of every call signature of every expression and its properties in the file. That is a superset of what the lint rule requests. All 1709 resolved in 79 ms (script below).
The type itself terminates
Forcing Promisify on concrete overloaded functions (1, 2 and 3 overloads, generic overloads) type-checks correctly in both tsc and tsgo. tsc reports 4174 instantiations.
Trigger
A recursive type walks function overloads and stops when IsEqual<Current, Previous> is true.
- With the type-fest 4.31+
IsEqual,<G>() => G extends A & G | G ? 1 : 2, it hangs. - With the older form,
<G>() => G extends A ? 1 : 2, it finishes in ~1 s.
All of these are needed to reproduce. Removing any one makes it finish:
- the recursive
PromisifyInner, - the
Clientclass with acallgetter, - the generic
createHandlerconstrained toProcedureTree, expect(vi.mocked(createHandler))(vitest'sMockedFunctiontype).
Stack (SIGQUIT on the hung process, trimmed; full dump attached as stack.txt):
tsgolint/internal/rules/no_misused_promises ...
typescript-go/internal/checker.(*Checker).getReturnTypeOfSignature
.instantiateType → .instantiateTypeWithAlias → .instantiateTypeWorker
.getConditionalTypeInstantiation → .getConditionalType
...458 frames elided...
.inferFromTypes (inference.go:89 / :98)
.inferFromTypeArguments (inference.go:311)
.inferFromTypes
.inferFromTypeArguments
... (repeats, same source/target pointers on each inferFromTypes call)
.fillMissingTypeArguments (checker.go:21859)
🙂 Expected behavior
Expected
The checker terminates like tsc does. If the type is too deep, it should report or bail out at the instantiation and depth limits, not loop.
Additional information about the issue
attaching stacktrace
- Lenguaje dominante
- Go
- Estrellas
- 112k
- Forks
- 15.4k
- Merge medio
- 2 d 21 h
- PR fusionados (30 d)
- 126
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/TypeScript
-
Won't Fix
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
microsoft/TypeScript#65107 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Native API: formatDiagnosticsWithColorAndContext drops related information without a file locationPosiblemente ocupada @timurzvural la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
microsoft/TypeScript#65087 ·
Los mantenedores suelen responder en 1 día
-
TS7 LSP: documentHighlight returns nothing when the file path contains '@'Quizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. AbiertoBug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
microsoft/TypeScript#64758 ·
Los mantenedores suelen responder en 1 día
-
Language server (tsc --lsp) exits with code 1 after `shutdown` and `exit`Posiblemente ocupada @rajnish-verma-22172 la tomó hace 13 días. AbiertoBug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
microsoft/TypeScript#64742 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Class names `eval` and `arguments` are not reported as invalid strict mode bindingsPosiblemente ocupada @dmety la tomó hace 26 días. AbiertoBug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
microsoft/TypeScript#64661 ·
Los mantenedores suelen responder en 1 día
Todos los issues de microsoft/TypeScript
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
agent-butler-finding chore
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
jordansmall/spindrift#6318 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Eyevinn/moqlivemock#166 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
JakeChampion/lang#14091 ·
Los mantenedores suelen responder en 1 día
-
batcher: BAF send context leaks per batchPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
hyperledger/fabric-x-orderer#1409 ·
Los mantenedores suelen responder en 3 días