unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 68113@debbugs.gnu.org
Subject: bug#68113: Wrong error message triggered in cl--generic-standard-method-combination
Date: Sat, 30 Dec 2023 10:46:42 +0000	[thread overview]
Message-ID: <ZY_1Eu3IcEJ-0gEN@ACM> (raw)
In-Reply-To: <jwvzfxt7xgd.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

Thanks for the quick reply yesterday.

On Fri, Dec 29, 2023 at 12:24:36 -0500, Stefan Monnier wrote:
> Hi Alan,

> > In my development version of Emacs (based on the master branch) I get a
> > backtrace with the error message being:

> >     Error: wrong-type-argument (symbolp mets-by-qual)

> > This occurs during the execution of cl-generic-combine-methods, whose
> > code starts:

> > (defun cl--generic-standard-method-combination (generic methods)
> >   (let ((mets-by-qual ()))
> >     (dolist (method methods)
> >       (let ((qualifiers (cl-method-qualifiers method)))
> >         (if (eq (car qualifiers) :extra) (setq qualifiers (cddr qualifiers)))
> >         (unless (member qualifiers '(() (:after) (:before) (:around)))
> >           (error "Unsupported qualifiers in function %S: %S"
> >                  (cl--generic-name generic) qualifiers))
> >         (push method (alist-get (car qualifiers) mets-by-qual))))

> > It is the last line that is signalling the error.  The pertinent line
> > from the backtrace which is the expansion of that last line reads:

> >     (let* ((k (car qualifiers)) (p (assq k mets-by-qual)) (v (cons method (cdr p)))) (progn (if p (setcdr p v) (progn (signal 'wrong-type-argument (list 'symbolp 'mets-by-qual)))) v))

> > ..  The error is, in actual fact, the failure to find an entry for (car
> > qualifiers) in the alist mets-by-qual.  The error message given is
> > rubbish and more than a little misleading.  mets-by-qual is clearly a
> > symbol.

> [ Side note: not finding an entry for (car qualifiers) in the above code
>   is perfectly normal (it's the most common case, even).  The code only
>   finds such an entry when there are several applicable methods (and
>   they have the same set of qualifiers).  ]

> Hmm... the error occurs during macroexpansion, because the
> macroexpansion of the `push` above should be (and is, normally):

>     ELISP> (macroexpand '(push method (alist-get (car qualifiers) mets-by-qual)))
>     (let*
>         ((k (car qualifiers)) (p (assq k mets-by-qual))
>          (v (cons method (cdr p))))
>       (progn
>         (if p (setcdr p v)
>           (setq mets-by-qual (cons (setq p (cons k v)) mets-by-qual)))
>         v))
    
This was a good hint, thanks.  The most likely source of the (signal
.....) form would seem to be the clause handling `setq' in
macroexp--expand-all.  I suspected it might be caused, somehow, by
symbolp not recognising symbols with position as symbols.  But I
tightened up all the entry points, and disabled SWPs, and I still can't
get the code in macroexp--expand-all to printf a message for
mets-by-qual.

>     ELISP>

> 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.

> 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.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2023-12-30 10:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-29 16:50 bug#68113: Wrong error message triggered in cl--generic-standard-method-combination Alan Mackenzie
2023-12-29 17:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-30 10:46   ` Alan Mackenzie [this message]
2023-12-31 20:01     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-01 19:36       ` Alan Mackenzie
2024-01-02  4:39         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-07 18:52           ` Alan Mackenzie
2024-01-07 19:12             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZY_1Eu3IcEJ-0gEN@ACM \
    --to=acm@muc.de \
    --cc=68113@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).