bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Fri, 4 Aug 2023 13:22:58 +0000

Hello, Stefan, Mattias, and Eric.

On Thu, Aug 03, 2023 at 10:43:16 -0400, Stefan Monnier wrote:

[ .... ]

> AFAICT the problem is that OT1H `symbols-with-pos-enabled` is
> non-nil while loading the second file, but OTOH positions aren't
> stripped from the resulting code.

> So in `cl--labels-convert` when we check

>     (eq f (car cl--labels-convert-cache))

[ .... ]

> I don't know why `symbols-with-pos-enabled` is non-nil at that point (I
> thought we only enabled it wile byte-compiling), ....

This is not quite the case.  symbols-with-pos-enabled gets erroneously
bound to t in internal-macroexpand-for-load (emacs-lisp/macroexp.el).
This is the cause of the bug; in cl--labels-convert it causes the first
eq to return non-nil when comparing 'equal to #<symbol equal at 194>.

Removing that binding fixes the problem.  This does not affect make
bootstrap or make check.

The necessary patch is:



diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el
index b05aba3e1a7..ea838f5b7b2 100644
--- a/lisp/emacs-lisp/macroexp.el
+++ b/lisp/emacs-lisp/macroexp.el
@@ -799,8 +799,7 @@ macroexp--debug-eager
 
 (defun internal-macroexpand-for-load (form full-p)
   ;; Called from the eager-macroexpansion in readevalloop.
-  (let ((symbols-with-pos-enabled t)
-        (print-symbols-bare t))
+  (let ((print-symbols-bare t))
     (cond
      ;; Don't repeat the same warning for every top-level element.
      ((eq 'skip (car macroexp--pending-eager-loads)) form)


Stefan, it would still be nice for cl--labels-convert-cache to get
initialised each time it gets used.

Please try out the patch, and if all is well I can commit it and close
the bug.

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]