bug#42088: [feature/native-comp] Lockup on opening TypeScript files

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Okay after some digging I think I've an idea of what is going on:
>>
>> the code was hanging in `typescript--ensure-cache' in the loop
>>
>> (cl-loop while (re-search-forward typescript--quick-match-re-func nil t)...
>>
>> This because typescript--quick-match-re-func is not set correctly going
>> back and back this is because `typescript--available-frameworks' is set
>> to nil.
>
> Hmm... I'm afraid I can't follow this.  Could you provide some details?

Sure,

this is how `typescript--available-frameworks' is computed in
typescript-mode.el.

===
(defconst typescript--available-frameworks
  (cl-loop with available-frameworks
        for style in typescript--class-styles
        for framework = (plist-get style :framework)
        unless (memq framework available-frameworks)
        collect framework into available-frameworks
        finally return available-frameworks)
  "List of available typescript frameworks symbols.")
===

The loop is expanded in:

===
(cl-block nil
    (let*
        ((available-frameworks nil)
         (--cl-var-- typescript--class-styles)
         (style nil)
         (framework nil)
         (available-frameworks nil)
         (--cl-var-- t))
      (while
          (consp --cl-var--)
        (setq style
              (car --cl-var--))
        (setq framework
              (plist-get style :framework))
        (if
            (memq framework available-frameworks)
            (progn)
          (setq available-frameworks
                (nconc available-frameworks
                       (list framework))))
        (setq --cl-var--
              (cdr --cl-var--))
        (setq --cl-var-- nil))
      available-frameworks))
===

If the two --cl-var-- are confused we never iterate and the block
evaluates to nil.  As a result `typescript--available-frameworks' was
(incorrectly) set to nil.

>> IIUC the reason for that is: cl-macs is expanding cl-loop using various
>> `--cl-var--', these looks the same but each of this is a separete
>> uninterned symbol.  The native compiler squash them all toghether having
>> to pass them through the reader and a simple testcase like this fails to
>> behave as expected.
>
> How/where exactly do they get squashed?
>
> The printer is normally able to preserve this info (printing #:<foo>
> instead of <foo> for uninterned symbols and using #= and such the refer
> to exactly that symbol) when printing code into the .elc file, so I'm
> wondering why it gets lost when going through the native compiler.

Yes that's the conclusion I came-up shortly after.  Turned out that the
native compiler was not configuring the printer to handle uninterned
symbols, so the fix I pushed Sunday:

7f8512765a * Setup correctly the printer while dumping objs in native CU 
(bug#42088)

I corrected myself and discussed the fix in a mail sent into this thread
but unfortunately this got lost.  My sdf mail lost a number of mails in
the last days both incoming and out-coming (possibly including one I sent
you :).

This mail lossage has been extremely annoying sorry.

  Andrea