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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> > 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?
>> That's right.
> OK.  So perhaps binding symbols-with-pos-enabled to nil around that eq
> call could be the way to go.

Indeed, that's the patch I suggested.  I think it's fundamentally right,
but it doesn't work (yet) because it bumps into the optimization bug
introduced by making `eq` depend on `symbols-with-pos-enabled`  :-(

>> > 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)?
>> There might.  The current hack is the best I could come up with.
> I'm not criticising the hack, not at all!  But it could be better
> commented, and the doc string for cl--labels-convert could be more
> informative.

It would help if you could send a (rough) patch showing what comment
you'd have liked to see.

> The "why" is missing - why is necessary to handle `function' as
> a macro?

I couldn't really think of any alternative for it ("it" being to
implement `cl-labels` and `cl-flet`).  FWIW, the pre-cl-lib code did it
differently by duplicating `macroexp--expand-all` wholesale and then
tweaking its handling of `function` in an ad-hoc way.

BTW, there's a standard solution from Common Lisp to get rid of this
hack: implement the `&whole` macro argument.
[Macro Lambda Lists](http://clhs.lisp.se/Body/03_dd.htm)

> I think it's to inhibit the processing of `function' as function
> somewhere else, but where and why?

It's not a function but a special operator, which is thus handled in
a hard-coded way by `macroexp--expand-all`.

>> I'm not completely sure we agree yet on what is "the original bug", but
>> obviously I agree with  your sentence :-)
> I meant bug #65017.  I committed a fix for it yesterday using the patch
> I posted here on Sunday, and closed the bug.

FWIW my notion of "the original bug" should be fixed by the patch below
(modulo the above-mentioned optimization bug which makes the patch
ineffective).

BTW, I pushed an extended version of that patch which additionally does
what you suggested we should do (and which I claimed wouldn't work),
i.e. flush the cache (I originally couldn't see where to flush it).
I believe this does fix the original problem even in the remaining
corner cases, despite the optimization bug.


        Stefan


diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index 0a3181561bd..a405ae67691 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -2037,7 +2037,9 @@ cl--labels-convert
    ;; *after* handling `function', but we want to stop macroexpansion from
    ;; being applied infinitely, so we use a cache to return the exact `form'
    ;; being expanded even though we don't receive it.
-   ((eq f (car cl--labels-convert-cache)) (cdr cl--labels-convert-cache))
+   ((let ((symbols-with-pos-enabled nil))
+      (eq f (car cl--labels-convert-cache)))
+    (cdr cl--labels-convert-cache))
    (t
     (let* ((found (assq f macroexpand-all-environment))
            (replacement (and found