GNU bug report logs - #68113
Wrong error message triggered in cl--generic-standard-method-combination

Previous Next

Full log

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

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 68113 <at> debbugs.gnu.org
Subject: Re: bug#68113: Wrong error message triggered in
 cl--generic-standard-method-combination
Date: Sun, 7 Jan 2024 18:52:55 +0000

Hello, Stefan.

On Mon, Jan 01, 2024 at 23:39:57 -0500, Stefan Monnier wrote:
> > , 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.

> But as I pointed out, the normal macroexpansion does (ii), so the
> problem *is* in the wrong macroexpansion.

Yes indeed.

> > That line of code is poor.  It assumes that (alist-get (car qualifiers)
> > mets-by-qual) will always return a list element,

> No, it doesn't.  The `gv-expander` for `alist-get` handles that case
> just fine (tho for some reason not in your case, obviously).

> > and fails to make any checks.  It fails to check that qualifiers is
> > a non-empty list before taking its car.

> It's on purpose.  The "nil" case is the common case, actually.
> This has been working fine since Emacs-25, remember.

Yes.

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

> I already did.

> Did you try the patch I sent?

Yes I did, thanks.  It showed up the real problem.

I had modified the macroexpansion system in an attempt to use the
framework in macroexp--expand-all but without the "base case", by
fset'ing macroexp-macroexpand temporarily to an identity function.  This
was an attempt to strip symbols with position of their positions for bug
#67455, getting lambda positions into the doc strings.  In the end this
attempt was hopeless, but I spent quite some time on it.

I hadn't realised that macro expansion was central to gv.el.  Bug #68113
might be a real bug, but I somehow doubt it.  I'll close it as not a
bug.

Sorry to have wasted your time in the process.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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