From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#58396: 29.0.50; Optimization failure for add-to-list Date: Mon, 10 Oct 2022 10:59:04 -0400 Message-ID: References: <87o7uknkyx.fsf@gnus.org> <87fsfwnkl4.fsf@gnus.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11302"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: German Pacenza , 58396@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 10 17:13:14 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ohuSu-0002ha-WC for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Oct 2022 17:13:13 +0200 Original-Received: from localhost ([::1]:54684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohuSt-0008Ti-V2 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Oct 2022 11:13:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60462) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohuGA-0000b0-Uh for bug-gnu-emacs@gnu.org; Mon, 10 Oct 2022 11:00:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50476) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ohuGA-0001vl-Je for bug-gnu-emacs@gnu.org; Mon, 10 Oct 2022 11:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ohuGA-0007Tj-2O for bug-gnu-emacs@gnu.org; Mon, 10 Oct 2022 11:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Oct 2022 15:00:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58396 X-GNU-PR-Package: emacs Original-Received: via spool by 58396-submit@debbugs.gnu.org id=B58396.166541396128669 (code B ref 58396); Mon, 10 Oct 2022 15:00:01 +0000 Original-Received: (at 58396) by debbugs.gnu.org; 10 Oct 2022 14:59:21 +0000 Original-Received: from localhost ([127.0.0.1]:49554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ohuFU-0007SK-Hq for submit@debbugs.gnu.org; Mon, 10 Oct 2022 10:59:20 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45011) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ohuFS-0007S6-7K for 58396@debbugs.gnu.org; Mon, 10 Oct 2022 10:59:18 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7A63E100189; Mon, 10 Oct 2022 10:59:12 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 990AB10008C; Mon, 10 Oct 2022 10:59:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1665413946; bh=l0024sbFuI6o5rMRIQWJWIPxwzq9ls2bQ/n4jMYzzP0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=oaJz4EBgRN73fA6+mIagR8gwVqmAsfOddV6Yks/DeW1cyzE2+92juFjoKjN8ro4ZY J0IyN+ZNGmw/Pk85uqV0Av21LZbT5AkGUZojMX6kQNORIgt2X8pfytlXBykSP7hGoM nbsxQdfMbNdQ7mVJMg5Bw2e4B9ehBItq2fxa03K2xKbwbVu0uYrTZSvxNld5NiasmR th6GyeC/NFDEp/xTyELb676+X/zF4zf3mXAOjUsQQr+FmClcISuf9864UQec9i170G pZg+e7Qwz/kmnB5NmgeTjtDFblV8h8S2XEPu05mae5EFK6nXwMlgUh5my+PCpXAPNF H2mOOPqo1NCBw== Original-Received: from pastel (65-110-220-202.cpe.pppoe.ca [65.110.220.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2DCE812014D; Mon, 10 Oct 2022 10:59:06 -0400 (EDT) In-Reply-To: <87fsfwnkl4.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 10 Oct 2022 10:34:15 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:245030 Archived-At: Lars Ingebrigtsen [2022-10-10 10:34:15] wrote: > Lars Ingebrigtsen 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 # 2) >>> >>> With toggle-debug-on-error: >>> >>> Debugger entered--Lisp error: (wrong-number-of-arguments #>> 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) > #)(((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