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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 4 Aug 2023 16:43:12 +0000
> Cc: monnier@iro.umontreal.ca, mattias.engdegard@gmail.com,
>   65017@debbugs.gnu.org, eric.marsden@risk-engineering.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > If internal-macroexpand-for-load is "verboten" from being called by
> > the byte-compiler, I'd expect an assertion in it to that effect.
> > Because someone, some day, might easily forget and call that function
> > in the byte-compiler.
> 
> I don't think there's any such prohibition in this case.  The function is
> called only from readevalloop in src/lread.c as part of loading a .el
> file.  It is probable that an eval-when-compile could cause a .el file to
> be loaded during a byte compilation.  This would call
> internal-macroexpand-for-load with symbols-with-pos-enabled non-nil, I
> think.

But then, if the caller binds this variable non-nil, the problem will
again rear its ugly head?

> > > 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."?
> 
> > Something like that, perhaps even stronger.  And maybe an explanation
> > what kind of problems could using them outside of the byte compiler
> > cause.
> 
> OK.  Maybe ".... They shouldn't normally be used otherwise.  Doing so can
> cause unexpected results with basic Emacs functions such as `eq' and
> `equal'."?

That's a good start, thanks.