GNU bug report logs - #58396
29.0.50; Optimization failure for add-to-list

Previous Next

Full log

Message #16 received at 58396 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Mon, 10 Oct 2022 10:59:04 -0400

Lars Ingebrigtsen [2022-10-10 10:34:15] wrote:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>>> emacs -Q
>>> (setq tab-always-indent 'complete)
>>> (add-to-list pac ;; without the quote. Press TAB after the 'c'
>>>
>>> Result:
>>> Completion succeeds but I get the following in the echo area:
>>> Warning: Optimization failure for add-to-list: Handler:
>>> add-to-list--anon-cmacro
>>> (wrong-number-of-arguments #<subr add-to-list--anon-cmacro> 2)
>>>
>>> With toggle-debug-on-error:
>>>
>>>   Debugger entered--Lisp error: (wrong-number-of-arguments #<subr
>>> add-to-list--anon-cmacro> 2)
>>
>> This seems like it's the same problem as reported in bug#58148 (so I'm
>> merging the two reports).
>
> I don't quite understand the calling sequence how we end up here; I've
> added Stefan to the CCs -- he wrote `elisp--local-variables' back in
> 2014:
>
> Debugger entered--Lisp error: (wrong-number-of-arguments ((t) (form keymap
> key definition) (ignore keymap key definition) (keymap--compile-check key)
> form) 2)
>   keymap-set--anon-cmacro((keymap-set elisp--witness--lisp) elisp--witness--lisp)
>   apply(keymap-set--anon-cmacro (keymap-set elisp--witness--lisp) elisp--witness--lisp)
>   macroexp--compiler-macro(keymap-set--anon-cmacro (keymap-set elisp--witness--lisp))
>   #f(compiled-function (form func)
> #<bytecode -0x18f8a3887af7552>)(((keymap-set elisp--witness--lisp))
> keymap-set)
>   macroexp--expand-all((keymap-set elisp--witness--lisp))
>   macroexpand-all((keymap-set elisp--witness--lisp))
>   elisp--local-variables()

Hmm... we should arrange for this `macroexpand-all` call not to emit any
messages (and it should arguably also skip the compiler-macros) since we
know it'll often be used on code that's not (yet) valid.

I'm not sure which part you don't understand above, so I'll only explain
the general situation: to allow completion of local variable names, we
analyze the surrounding code, but in order to do that without having to
write ad-hoc code that knows about all the macros out there that can
introduce new vars, we take the "surrounding code" and macroexpand the
hell out of it so that we can then traverse the result looking only for
`let/let*/lambda/condition-case`.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.