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: Thu, 3 Aug 2023 16:43:41 +0000 Message-ID: References: <8B08E514-B2D5-48F5-BA90-4F5A9492F8F9@gmail.com> 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="4900"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 65017@debbugs.gnu.org, Eric Marsden To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 03 18:44:11 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 1qRbQp-00018c-Bg for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 03 Aug 2023 18:44:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qRbQj-0002kh-6q; Thu, 03 Aug 2023 12:44:05 -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 1qRbQg-0002kJ-Jx for bug-gnu-emacs@gnu.org; Thu, 03 Aug 2023 12:44:02 -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 1qRbQg-0002uj-CG for bug-gnu-emacs@gnu.org; Thu, 03 Aug 2023 12:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qRbQg-0002eO-8i for bug-gnu-emacs@gnu.org; Thu, 03 Aug 2023 12:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Aug 2023 16:44:02 +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.169108103110164 (code B ref 65017); Thu, 03 Aug 2023 16:44:02 +0000 Original-Received: (at 65017) by debbugs.gnu.org; 3 Aug 2023 16:43:51 +0000 Original-Received: from localhost ([127.0.0.1]:52815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRbQV-0002ds-1G for submit@debbugs.gnu.org; Thu, 03 Aug 2023 12:43:51 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:18348) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRbQS-0002dc-N0 for 65017@debbugs.gnu.org; Thu, 03 Aug 2023 12:43:49 -0400 Original-Received: (qmail 25077 invoked by uid 3782); 3 Aug 2023 18:43:41 +0200 Original-Received: from acm.muc.de (p4fe157c8.dip0.t-ipconnect.de [79.225.87.200]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 03 Aug 2023 18:43:41 +0200 Original-Received: (qmail 23975 invoked by uid 1000); 3 Aug 2023 16:43:41 -0000 Content-Disposition: inline In-Reply-To: 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:266605 Archived-At: Hello, Stefan. On Thu, Aug 03, 2023 at 10:43:16 -0400, Stefan Monnier wrote: > > We can simplify your nice little test case to > > ------- first file ----------- > > (require 'cl-macs) > > (defun zeta () (cl-flet () #'equal)) > > ------- second file --------- > > (defun eta () (cl-flet () (funcall #'equal 12 34))) > > ------------------------------ > > and indeed, the leak is in cl--labels-convert-cache which will contain > > `equal` as a symbol-with-pos after byte-compiling the first file, and this > > causes trouble in the second file. > > cl--labels-convert-cache contains > > (# function #) > > and the function `eta` is consequently defined as > > (closure (t) nil (progn (# 12 34))) > > where 49 is the position of `equal` in the first file. > Thanks Mattias. > AFAICT the problem is that OT1H `symbols-with-pos-enabled` is > non-nil while loading the second file, but OTOH positions aren't > stripped from the resulting code. As I suggested in my other post, it might be a "simple" problem of cache invalidation. Why is the value from the first compilation hanging around until the second one? > So in `cl--labels-convert` when we check > (eq f (car cl--labels-convert-cache)) > we get when `f` is just `equal` whereas the cache contains > the sympos, but that sympos is not stripped later on. > I don't know why `symbols-with-pos-enabled` is non-nil at that point (I > thought we only enabled it wile byte-compiling), .... I believe that is indeed the case. > .... but assuming there's a good reason for it, I tried to work around > the problem with the patch below which is conceptually correct (indeed > we should only return (cdr cl--labels-convert-cache) only in the case > where `f` is exactly the very same object as (car > cl--labels-convert-cache)). > Sadly, it doesn't seem to help for a reason that escapes me. Setting symbols-with-pos-enabled to nil does nothing other than disable the mechanisms which handle symbols with position. Any such symbols which exist will continue to be swp, but will no longer be EQ to the base symbol, or other swp's with the same base symbol. > The *Messages* buffer says: > For information about GNU Emacs and the GNU system, type C-h C-a. > Compiling .../tmp/foo1.el... > Self-rewrite # to #'# (t) > Compiling .../tmp/foo1.el...done > Wrote .../tmp/foo1.elc > Self-rewrite equal to #'# (t) > Self-rewrite # to #'# (t) > where the middle "self-rewrite" is the culprit. > Apparently > (let ((symbols-with-pos-enabled nil)) > (eq f (car cl--labels-convert-cache))) > returned non-nil when `f` was the bare `equal` and the `car` returned > the sympos. How can that be? I thought `eq` should really be the > good old "pointer equality" when `symbols-with-pos-enabled` is nil. > What am I missing? > Stefan > diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el > index 0a3181561bd..bc71f565f3b 100644 > --- a/lisp/emacs-lisp/cl-macs.el > +++ b/lisp/emacs-lisp/cl-macs.el > @@ -2037,7 +2039,12 @@ > ;; *after* handling `function', but we want to stop macroexpansion from > ;; being applied infinitely, so we use a cache to return the exact `form' > ;; being expanded even though we don't receive it. > - ((eq f (car cl--labels-convert-cache)) (cdr cl--labels-convert-cache)) > + ((let ((symbols-with-pos-enabled nil)) > + (eq f (car cl--labels-convert-cache))) > + (let ((print-symbols-bare nil)) > + (message "Self-rewrite %S to %S (%S)" f (cdr cl--labels-convert-cache) > + symbols-with-pos-enabled)) > + (cdr cl--labels-convert-cache)) > (t > (let* ((found (assq f macroexpand-all-environment)) > (replacement (and found -- Alan Mackenzie (Nuremberg, Germany).