TSC fatal error: Maximum call stack size exceeded

[axetroy]

🔎 Search Terms

Maximum call stack size exceeded

🕗 Version & Regression Information

• This is a crash
• This changed between versions 5.2.2 and 5.2.2_
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
• I was unable to test this on prior versions because _______

⏯ Playground Link

No response

💻 Code

function test(fn) {
    const composed = function (...args) {}

    Object.defineProperty(composed, 'name', {
        value: composed.fn + '_test'
    })

    return composed
}

and the compile with tsc

$ npx tsc test.js --allowJs --noEmit
Maximum call stack size exceeded

🙁 Actual behavior

stack trace:
RangeError: Maximum call stack size exceeded
    at getTypeOfSymbol (C:\Users\Admin\gpm\192.168.0.254\group_name\project\node_modules\typescript\lib\typescript.js:54746:29)
    at getExpandedParameters (C:\Users\Admin\gpm\192.168.0.254\group_name\project\node_modules\typescript\lib\typescript.js:55655:26)
    at signatureToSignatureDeclarationHelper (C:\Users\Admin\gpm\192.168.0.254\group_name\project\node_modules\typescript\lib\typescript.js:50913:32)
    at createTypeNodesFromResolvedType (C:\Users\Admin\gpm\192.168.0.254\group_name\project\node_modules\typescript\lib\typescript.js:50672:31)
    at createTypeNodeFromObjectType (C:\Users\Admin\gpm\192.168.0.254\group_name\project\node_modules\typescript\lib\typescript.js:50504:27)
    at visitAndTransformType (C:\Users\Admin\gpm\192.168.0.254\group_name\project\node_modules\typescript\lib\typescript.js:50440:26)
    at createAnonymousTypeNode (C:\Users\Admin\gpm\192.168.0.254\group_name\project\node_modules\typescript\lib\typescript.js:50375:22)
    at typeToTypeNodeWorker (C:\Users\Admin\gpm\192.168.0.254\group_name\project\node_modules\typescript\lib\typescript.js:50189:18)
    at typeToTypeNodeHelper (C:\Users\Admin\gpm\192.168.0.254\group_name\project\node_modules\typescript\lib\typescript.js:49969:26)
    at C:\Users\Admin\gpm\192.168.0.254\group_name\project\node_modules\typescript\lib\typescript.js:49904:136

🙂 Expected behavior

There should not error

Additional information about the issue

No response

[Andarist]

You need to understand that if you don't provide a repro case the chances for your problem being fixed are less than 0. It's virtually impossible to guess what the problem might be from the given (lack of) information.

[axetroy]

Sorry, I can't provide any more information at this time.

Because this appears in my project.

It was working normally until the last few commits caused this error.

I'm checking one by one which piece of code caused it

[axetroy]

@Andarist

Here is the reproducible code

class Lock {}

/**
 * 让这个函数，始终只能运行一个
 * @param {Function} fn
 * @returns {Function}
 */
function singlable(fn) {
    const lock = new Lock()

    const composed = async function (...args) {
        try {
            await lock.lock()
            return await fn(...args)
        } finally {
            lock.unlock()
        }
    }

    Object.defineProperty(composed, 'name', {
+        value: composed.fn + '_singlable'
    })

    return composed
}

Compile it with tsc

$ npx tsc test.js --allowJs --noEmit
Maximum call stack size exceeded

[Andarist]

Could u also inline Lock here and recheck if it still reproduces the problem? The repro should be self-contained and this relies on an external import

[axetroy]

I have actually highlighted the above problem, and it has nothing to do with Lock.

just remove this code, and it will works again

-    Object.defineProperty(composed, 'name', {
-       value: composed.fn + '_singlable'
-    })

or change it to

    Object.defineProperty(composed, 'name', {
-       value: composed.fn + '_singlable'
+       value: "whatever..."
    })

[Andarist]

Thanks for the repro! The bug is pretty old - I can repro it even with TS 3.3

[Andarist]

This is a circularity error combined with non-existent property. The problem is that when serializing the type within reportNonexistentProperty we end up calling isReadonlyAssignmentDeclaration which calls checkExpressionCached(d.arguments[2]) for this expando declaration member. When resolving the type of this descriptor argument we run into the mentioned circularity because it tries to call reportNonexistentProperty again.

Partially the problem is in the fact that reportNonexistentProperty gets called before we have a chance to assign the cached type of this expression. There is a way to use addLazyDiagnostic to overcome this problem slightly - but those are sometimes called eagerly despite being "lazy" (see checkSourceFileWithEagerDiagnostics). So in those scenarios, it doesn't solve anything.

The circularity could be detected (based on pushTypeResolution+popTypeResolution but I'm not sure where tracking for it should be added here. It would also be a surgical fix and it kind of feels that other typeToString calls might be affected by this problem as well.

Maybe some TS team member could advise on how this would be best handled (implementation-wise).

[axetroy]

@ahejlsberg could you remove Need More Infos Label from this issuse since it's reproducable.