From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#68113: Wrong error message triggered in cl--generic-standard-method-combination Date: Mon, 1 Jan 2024 19:36:29 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5067"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68113@debbugs.gnu.org, acm@muc.de To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 01 20:37:25 2024 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 1rKO6G-0001Aa-0V for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Jan 2024 20:37:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rKO5u-0005JE-Mp; Mon, 01 Jan 2024 14:37:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rKO5s-0005IG-CZ for bug-gnu-emacs@gnu.org; Mon, 01 Jan 2024 14:37:00 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rKO5s-00043s-3R for bug-gnu-emacs@gnu.org; Mon, 01 Jan 2024 14:37:00 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rKO5t-0000dh-Kg for bug-gnu-emacs@gnu.org; Mon, 01 Jan 2024 14:37:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Jan 2024 19:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68113 X-GNU-PR-Package: emacs Original-Received: via spool by 68113-submit@debbugs.gnu.org id=B68113.17041378042435 (code B ref 68113); Mon, 01 Jan 2024 19:37:01 +0000 Original-Received: (at 68113) by debbugs.gnu.org; 1 Jan 2024 19:36:44 +0000 Original-Received: from localhost ([127.0.0.1]:48811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKO5c-0000dC-55 for submit@debbugs.gnu.org; Mon, 01 Jan 2024 14:36:44 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:21579) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKO5Z-0000cx-A8 for 68113@debbugs.gnu.org; Mon, 01 Jan 2024 14:36:42 -0500 Original-Received: (qmail 29878 invoked by uid 3782); 1 Jan 2024 20:36:32 +0100 Original-Received: from acm.muc.de (p4fe15c24.dip0.t-ipconnect.de [79.225.92.36]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 01 Jan 2024 20:36:31 +0100 Original-Received: (qmail 10054 invoked by uid 1000); 1 Jan 2024 19:36:29 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:277195 Archived-At: Hello, Stefan. I think we've both been confused. The code which signalled the error was (push method (alist-get (car qualifiers) mets-by-qual)) , and at the time of calling, qualifiers was nil. So the call boiled down to (push method (alist-get nil mets-by-qual)) , and there was no element of mets-by-qual with a car of nil. So what can the push macro do? There's no list to push onto. It can generate code either (i) to signal an error; or (ii) to create a new element in the alist mets-by-qual with method being the single element of its cdr. In actual fact, it does (i), but (as reported in the bug report) gives the wrong message. It should say something like "void list" or "non-existent list", not "mets-by-qual isn't a symbol", and it should give further information to enable the working out of WHICH list doesn't exist. That line of code is poor. It assumes that (alist-get (car qualifiers) mets-by-qual) will always return a list element, and fails to make any checks. It fails to check that qualifiers is a non-empty list before taking its car. That's not to say I'm denying responsibility for the failure. It's almost certainly caused by my tentative alterations for bug #67455. But bug #68113, the current bug, is real - That wrong-argument-type error is definitely erroneous. It's possible it was also caused by my changes for bug #67455, but I don't have the energy to look into that at the moment. Would you please check the code that signaled that error (you wrote it, I think), and let me know whether you find anything suspicious in it. Thanks! On Sun, Dec 31, 2023 at 15:01:05 -0500, Stefan Monnier wrote: > >> I don't know why you're not getting that expansion, and I don't know > >> either why you're getting that > >> (signal 'wrong-type-argument (list 'symbolp 'mets-by-qual)) > > I don't know, either. :-( As I say, I've tried instrumenting the `setq' > > handling code in macroexp--expand-all, but haven't managed to get > > anything pertinent output. > Ah, indeed instead of `gv-delay-error` it could also come from > `macroexp--expand-all`. > The `macroexp.el` hunk below would rule that out, tho. > >> AFAICT this weird code is likely generated by `gv-delay-error` but > >> according to `grep` it's only used in `map-elt` so I can't see why it's > >> showing up here. > >> I'd start debugging this with something like `M-x trace-function RET > >> gv-get RET` and `M-x debug-on-entry RET gv-delay-error RET`. > >> [ Tho, presumably you're seeing this during the bootstrap, so you'll > >> probably want to add `message/debug` calls in the code instead. ] > > I am indeed seeing this in bootstrap, so it's message and a bit of prin1. > Did you get to see the offending code in one of the outputs of `gv-get`? > Hpw 'bout a test that tries to see when that code is generated, as in > the `gv.el` patch below? > Stefan > diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el > index 78601c0648e..5c461206820 100644 > --- a/lisp/emacs-lisp/macroexp.el > +++ b/lisp/emacs-lisp/macroexp.el > @@ -467,10 +467,10 @@ macroexp--expand-all > ,var > (signal 'setting-constant (list ',var)))) > ((symbolp var) > - `(signal 'setting-constant (list ',var))) > + (signal 'setting-constant (list var))) > (t > - `(signal 'wrong-type-argument > - (list 'symbolp ',var)))) > + (signal 'wrong-type-argument > + (list 'symbolp var)))) > nil 'compile-only var)))) > (push assignment assignments)) > (setq args (cddr args))) > diff --git a/lisp/emacs-lisp/gv.el b/lisp/emacs-lisp/gv.el > index 9f40c1f3c93..9cfd6d4b423 100644 > --- a/lisp/emacs-lisp/gv.el > +++ b/lisp/emacs-lisp/gv.el > @@ -86,6 +86,8 @@ gv-get > with a (not necessarily copyable) Elisp expression that returns the value to > set it to. > DO must return an Elisp expression." > + (message "Entering gv-get for %S" place) > + (let ((res > (cond > ((symbolp place) > (let ((me (macroexpand-1 place macroexpand-all-environment))) > @@ -118,7 +120,13 @@ gv-get > (let* ((setter (gv-setter head))) > (gv--defsetter head (lambda (&rest args) `(,setter ,@args)) > do (cdr place)))) > - (gv-get me do)))))))) > + (gv-get me do))))))) > + )) > + (if (string-match-p "(list 'symbolp 'mets-by-qual)" > + (prin1-to-string res)) > + (error "Gotcha!?")) > + (message "Exiting gv-get for %S: %S" place res) > + res)) > (defun gv-setter (name) > ;; The name taken from Scheme's SRFI-17. Actually, for SRFI-17, the argument -- Alan Mackenzie (Nuremberg, Germany).