TSC fatal error: Maximum call stack size exceeded #55889

Activity

1. Andarist commented on Sep 27, 2023

   

   Mateusz Burzyński (Andarist)

   on Sep 27, 2023

   Contributor

   More actions

   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.

   👍React with 👍1Reacted by Martin Johns
2. Anders Hejlsberg (ahejlsberg)

   added

   Needs More InfoThe issue still hasn't been fully clarifiedThe issue still hasn't been fully clarified

   on Sep 27, 2023
3. axetroy commented on Sep 28, 2023

   

   Axetroy (axetroy)

   on Sep 28, 2023

   Author

   More actions

   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
4. axetroy commented on Sep 28, 2023

   

   Axetroy (axetroy)

   on Sep 28, 2023

   Last edited by axetroy

   Author

   More actions

   Mateusz Burzyński (@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
5. Andarist commented on Sep 28, 2023

   

   Mateusz Burzyński (Andarist)

   on Sep 28, 2023

   Contributor

   More actions

   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
6. axetroy commented on Sep 28, 2023

   

   Axetroy (axetroy)

   on Sep 28, 2023

   Author

   More actions

   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..."
       })
7. Andarist commented on Sep 28, 2023

   

   Mateusz Burzyński (Andarist)

   on Sep 28, 2023

   Contributor

   More actions

   Thanks for the repro! The bug is pretty old - I can repro it even with TS 3.3
8. Andarist commented on Sep 28, 2023

   

   Mateusz Burzyński (Andarist)

   on Sep 28, 2023

   Contributor

   More actions

   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).
9. axetroy commented on Oct 6, 2023

   

   Axetroy (axetroy)

   on Oct 6, 2023

   Author

   More actions

   Anders Hejlsberg (@ahejlsberg) could you remove Need More Infos Label from this issuse since it's reproducable.
10. Gabriela Araujo Britto (gabritto)

    closed this as completedin #60690on Dec 5, 2024