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

Previous Next

Full log

View this message in rfc822 format

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

Hello, Mattias, and Stefan.

On Thu, Aug 03, 2023 at 11:39:33 +0200, Mattias Engdegård wrote:
> > Error: invalid-function (#<symbol equal at 95>)

> That is a symbol-with-position somehow leaking out.
> We can simplify your nice little test case to

> ------- first file -----------
> (require 'cl-macs)
> (defun zeta () (cl-flet () #'equal))
> ------- second file ---------
> (defun eta () (cl-flet () (funcall #'equal 12 34)))
> ------------------------------

> and indeed, the leak is in cl--labels-convert-cache which will contain `equal` as a symbol-with-pos after byte-compiling the first file, and this causes trouble in the second file.

> cl--labels-convert-cache contains

>   (#<symbol equal at 49> function #<symbol equal at 49>)

> and the function `eta` is consequently defined as

>   (closure (t) nil (progn (#<symbol equal at 49> 12 34)))

> where 49 is the position of `equal` in the first file.

First thoughts:

It would seem cl--labels-convert-cache is failing to get initialised,
somewhere.  Perhaps this is a problem of cache invalidation.  The
variable lacks a doc-string, which might otherwise have documented where
it is meant to be valid.  What does this variable mean?

cl--label-convert is defined as "Special macro-expander to rename
(function F) references in `cl-labels'.".  What does "rename (function
F) references" mean?  Is the term "name" in this context defined
anywhere?

> Stefan and Alan should have a word here but I doubt we should hack
> this in cl-macs.el somehow, should we?

If that's where the bug is, that's what we should fix.

> Making Ffuncall (etc) tolerant of symbol-with-pos isn't appealing
> either.

Definitely not!

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