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

Previous Next

Full log

Message #86 received at 65017 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: mattias.engdegard <at> gmail.com, 65017 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, eric.marsden <at> risk-engineering.org
Subject: Re: bug#65017: 29.1; Byte compiler interaction with cl-lib function
 objects, removes symbol-function
Date: Fri, 04 Aug 2023 20:54:40 +0300

> Date: Fri, 4 Aug 2023 16:43:12 +0000
> Cc: monnier <at> iro.umontreal.ca, mattias.engdegard <at> gmail.com,
>   65017 <at> debbugs.gnu.org, eric.marsden <at> risk-engineering.org
> From: Alan Mackenzie <acm <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.