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

[Alan Mackenzie]

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