GNU bug report logs - #65017
29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function

Previous Next

Full log

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

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: acm <at> muc.de,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 65017 <at> debbugs.gnu.org, Eric Marsden <eric.marsden <at> risk-engineering.org>
Subject: Re: bug#65017: 29.1; Byte compiler interaction with cl-lib function
 objects, removes symbol-function
Date: Tue, 8 Aug 2023 16:56:03 +0000

Hello, Stefan.

On Mon, Aug 07, 2023 at 22:44:29 -0400, Stefan Monnier wrote:
> > I suggest installing this patch into master.

> LGTM, thanks.

> >> > Stefan, it would still be nice for cl--labels-convert-cache to get
> >> > initialised each time it gets used.
> >> No, the problem is not initialization, as I pointed out.  The problem is
> >> that this `eq` should not consider a symbol equal to a sympos *ever*
> >> (contrary to most other uses of `eq` in macros).

> > Are you sure?

> Yes.

What about two SWPs with the same symbol but different positions?  If
they aren't considered EQ here, there will never be a match for the
first arm of the cond form in cl--labels-convert; then
cl--labels-convert-cache will get written, but never used.

And if, somehow, it does get used (the current code, I think), then (as
you write below) the argument F will get replaced by an F with the wrong
position.  Am I right, here?

Why must the F get replaced by a different F?  There must surely be a
way, a simpler way than the current cl--labels-convert, to retain the
current F (hence, not corrupting its position)?

[ .... ]

> > If cl--labels-convert-cache is being used
> > inside the byte compiler, it surely needs to consider #<symbol foo at
> > 42> and #<symbol foo at 60> as eq?

> No, it should not treat them equal (when it does, it introduces an
> incorrect sympos and can thus lead to error messages pointing at the
> wrong place).

Then isn't what is wrong here the introduction of the incorrect SWP
rather than treating the two SWPs as EQ?

This is obscure, difficult code.  :-(

We should think about committing a fix to the original bug, sometime,
too.

[ .... ]

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