From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function Date: Fri, 4 Aug 2023 16:43:12 +0000 Message-ID: References: <8B08E514-B2D5-48F5-BA90-4F5A9492F8F9@gmail.com> <83r0oivr7v.fsf@gnu.org> <83jzuavnm2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29700"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mattias.engdegard@gmail.com, 65017@debbugs.gnu.org, monnier@iro.umontreal.ca, eric.marsden@risk-engineering.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 04 18:44:34 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qRxuk-0007XP-HF for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Aug 2023 18:44:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qRxuO-0000af-Qt; Fri, 04 Aug 2023 12:44:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRxuM-0000aM-Da for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 12:44:10 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qRxuE-0000RZ-1e for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 12:44:10 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qRxuD-00050Z-V1 for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 12:44:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Aug 2023 16:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65017 X-GNU-PR-Package: emacs Original-Received: via spool by 65017-submit@debbugs.gnu.org id=B65017.169116740219191 (code B ref 65017); Fri, 04 Aug 2023 16:44:01 +0000 Original-Received: (at 65017) by debbugs.gnu.org; 4 Aug 2023 16:43:22 +0000 Original-Received: from localhost ([127.0.0.1]:54651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRxtZ-0004zT-TS for submit@debbugs.gnu.org; Fri, 04 Aug 2023 12:43:22 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:59771) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRxtX-0004zC-BH for 65017@debbugs.gnu.org; Fri, 04 Aug 2023 12:43:20 -0400 Original-Received: (qmail 93884 invoked by uid 3782); 4 Aug 2023 18:43:13 +0200 Original-Received: from acm.muc.de (pd953a874.dip0.t-ipconnect.de [217.83.168.116]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 04 Aug 2023 18:43:13 +0200 Original-Received: (qmail 28016 invoked by uid 1000); 4 Aug 2023 16:43:12 -0000 Content-Disposition: inline In-Reply-To: <83jzuavnm2.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:266695 Archived-At: Hello, Eli. On Fri, Aug 04, 2023 at 18:22:29 +0300, Eli Zaretskii wrote: > > Date: Fri, 4 Aug 2023 14:49:56 +0000 > > Cc: monnier@iro.umontreal.ca, mattias.engdegard@gmail.com, > > 65017@debbugs.gnu.org, eric.marsden@risk-engineering.org > > From: Alan Mackenzie > > > > 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 #. > > > 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. 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. > Btw, why was this binding added there to begin with? A good question. It was back in January 2022, I was getting eager macro expansion failures while trying to bootstrap (my development version of) Emacs. Binding that variable made those failures go away. It turns out, that was not the correct fix. Somehow that erroneous binding stayed in the code and got committed. > > > 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. OK. Maybe ".... They shouldn't normally be used otherwise. Doing so can cause unexpected results with basic Emacs functions such as `eq' and `equal'."? > Thanks. -- Alan Mackenzie (Nuremberg, Germany).