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

Previous Next

Full log

Message #80 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 18:22:29 +0300

> Date: Fri, 4 Aug 2023 14:49:56 +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>
> 
> > > 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.

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.

Btw, why was this binding added there to begin with?

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

Something like that, perhaps even stronger.  And maybe an explanation
what kind of problems could using them outside of the byte compiler
cause.

Thanks.

Previous Next

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