[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65017: 29.1; Byte compiler interaction with cl-lib function objects,
From: |
Alan Mackenzie |
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).
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, (continued)
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/10
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Stefan Monnier, 2023/08/11
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Mattias Engdegård, 2023/08/12
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Stefan Monnier, 2023/08/12
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Mattias Engdegård, 2023/08/12
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/12
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Stefan Monnier, 2023/08/12
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/13
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Stefan Monnier, 2023/08/13
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/14
bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function,
Alan Mackenzie <=
bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/09