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

Previous Next

Package: emacs;

Reported by: Eric Marsden <eric.marsden <at> risk-engineering.org>

Date: Wed, 2 Aug 2023 13:34:02 UTC

Severity: normal

Found in version 29.1

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


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

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

Stefan and Alan should have a word here but I doubt we should hack this in cl-macs.el somehow, should we?
Making Ffuncall (etc) tolerant of symbol-with-pos isn't appealing either.





This bug report was last modified 1 year and 338 days ago.

Previous Next


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