[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#47049: [feature/native] macro-expansion cycle when compiling comp.el
From: |
Andrea Corallo |
Subject: |
bug#47049: [feature/native] macro-expansion cycle when compiling comp.el |
Date: |
Fri, 12 Mar 2021 20:55:20 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
- bug#47049: [feature/native] macro-expansion cycle when compiling comp.el, Eli Zaretskii, 2021/03/10
- bug#47049: [feature/native] macro-expansion cycle when compiling comp.el, Andrea Corallo, 2021/03/10
- bug#47049: [feature/native] macro-expansion cycle when compiling comp.el, Eli Zaretskii, 2021/03/10
- bug#47049: [feature/native] macro-expansion cycle when compiling comp.el, Stefan Monnier, 2021/03/11
- bug#47049: [feature/native] macro-expansion cycle when compiling comp.el, Andrea Corallo, 2021/03/12
- bug#47049: [feature/native] macro-expansion cycle when compiling comp.el,
Andrea Corallo <=
- bug#47049: [feature/native] macro-expansion cycle when compiling comp.el, Stefan Monnier, 2021/03/12
- bug#47049: [feature/native] macro-expansion cycle when compiling comp.el, Andrea Corallo, 2021/03/12
- bug#47049: [feature/native] macro-expansion cycle when compiling comp.el, Stefan Monnier, 2021/03/12
- bug#47049: [feature/native] macro-expansion cycle when compiling comp.el, Andrea Corallo, 2021/03/12
- bug#47049: [feature/native] macro-expansion cycle when compiling comp.el, Eli Zaretskii, 2021/03/13
bug#47049: [feature/native] macro-expansion cycle when compiling comp.el, Eli Zaretskii, 2021/03/12