bug#47049: [feature/native] macro-expansion cycle when compiling comp.el

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> > I made some local modifications in comp.el, and used that modified
>>>> > comp.el for a while (by loading it manually at run time) to debug some
>>>> > problem.  Then I undid those local modifications of comp.el (by saying
>>>> > "git checkout") and said "make" to rebuild Emacs.  And I see this:
>>>> >
>>>> >     ELC      emacs-lisp/comp.elc
>>>> >   Warning: Eager macro-expansion skipped due to cycle:
>>>> >       => (load "comp.el") => (macroexpand-all (defalias 'comp-add-call-cstr  )) => (macroexpand (comp-loop-insn-in-block  )) => (load "comp.el")
>>>> >
>>>> > Why does this happen?
>>>>
>>>> I'm not sure, but I can reproduce it.
>>>>
>>>> I guess (just a guess) it might be because `comp-add-call-cstr' is using
>>>> a macro `comp-loop-insn-in-block' that is expanding with a
>>>> `cl-symbol-macrolet' inside? (no idea why this should be a problem).
>>>>
>>>> > could it be that while comp.el was modified it
>>>> > got native-compiled, and now that inconsistent comp.eln gets in the
>>>> > way?
>>>>
>>>> I think this has not to do specifically with native compilation.
>>>>
>>>> I see it goes away removing '(setq load-prefer-newer t)' from the
>>>> invocation tho.
>>>>
>>>> Perhaps somebody already more into the macro expansion business might
>>>> have some suggestion.
>>>
>>> Stefan, can you help, please?
>>
>> Nothing jumps at me by looking at the code.  I'll have to look at the
>> actual complete stacktrace I think.
>
> Cool didn't know was so easy to generate backtraces to debug this kind
> of issues.  At the bottom I attached the backtrace I produced and had a
> look into.
>
> IIUC while *loading* "comp.el" we try to advice `macroexpand' and
> consequentially we try to install a trampoline (was already compiled)
> for `macroexpand', this is supposed to be done by
> `comp-subr-trampoline-install' requiring "comp.el" to be loaded again!
>
> Assuming my analysis is correct I'm not sure what's the best work around
> for this condition.  WDYT?

Apparently moving the definition of `comp-subr-trampoline-install'
before the other code in comp.el solves the issue.  Not sure if is the
best way to fix this tho.

  Andrea