bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Hello Andrea,

Andrea Corallo <acorallo@gnu.org> writes:

> You mean with the whole compilation unit is compiled at speed 2?

No, all the `defun', `cl-defun', and `defmacro' are declared with
`(speed 1)`.

> Mmmh not sure I understand, if you macro expanded all the instances of
> this macro how can the macro matter given it's never called?

I am very curious about this point as well. At first, I expand the macro
without the declare form in the function definition in the macro
definition. Then I add the declare form to the functions generated by
the macro expansion. To my surprise, the crash still occurs.

In another test, I add the declare form to the function definition in
the macro definition, and expanded the macros. The crash can not be
reproduced. I remove all the declare form in the generated functions,
and the crash still can not be reproduced.

Thus I come to the conclusion that the declare form in the function
definition in the macro definition is what triggers the crash.

I do not know Emacs lisp much so I convinced myself that maybe macros in
Emacs lisp is different from macros in C++ and even if there is no
instance of using the macro it still get compiled in the native
compilation. Thus, I just reported what I have observed to you.

>
> I think we have to really understand what's happening here and if what
> you've observed is reproducible cause it does not make much sense to me
> ATM.
>
> Thanks for your investigation
>
>   Andrea

I guess you do not use Windows? Maybe I can setup a Windows VM so that I
can sent the VM to you and you can see the crash by yourselves. I also
wonder is there any way that we can check the C source code generated
from the Emacs lisp code before it is sent to the C compiler?

Thank you