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

[Alan Mackenzie]

Hello, Eli.

On Fri, Aug 04, 2023 at 17:04:36 +0300, Eli Zaretskii wrote:
> > Cc: Mattias Engdegård <mattias.engdegard@gmail.com>,
> >  65017@debbugs.gnu.org, Eric Marsden <eric.marsden@risk-engineering.org>
> > Date: Fri, 4 Aug 2023 13:22:58 +0000
> > From: Alan Mackenzie <acm@muc.de>

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

> Why "erroneously"? what are the rules for binding that variable to a
> non-nil value?

internal-macroexpand-for-load isn't being called in the context of a
byte compilation.  It might create a symbol with position which wrongly
matches, or fails to match, another symbol.  This is what has happened
in this bug.

> I don't see any of that documented in the "Symbols with Position" node
> of the ELisp manual.

Well, there is the sentence: "These objects are intended for use by the
byte compiler, which records in them the position of each symbol
occurrence and uses those positions in warning and error messages.".

Do you think this should be firmed up to something like:  "These objects
are for the use of the byte compiler, which records in them the position
of each symbol occurrence and uses those positions in warning and error
messages.  They shouldn't normally be used otherwise."?

-- 
Alan Mackenzie (Nuremberg, Germany).