[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42088: [feature/native-comp] Lockup on opening TypeScript files
From: |
Andrea Corallo |
Subject: |
bug#42088: [feature/native-comp] Lockup on opening TypeScript files |
Date: |
Tue, 30 Jun 2020 08:06:47 +0000 (UTC) |
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
bug#42088: [feature/native-comp] Lockup on opening TypeScript files, Sebastian Sturm, 2020/06/29