From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function Date: Thu, 03 Aug 2023 17:00:53 -0400 Message-ID: References: <8B08E514-B2D5-48F5-BA90-4F5A9492F8F9@gmail.com> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29421"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 65017@debbugs.gnu.org, Eric Marsden To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 03 23:02: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 1qRfSr-0007VC-5q for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 03 Aug 2023 23:02:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qRfSO-0005sS-ME; Thu, 03 Aug 2023 17:02:04 -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 1qRfSN-0005sJ-87 for bug-gnu-emacs@gnu.org; Thu, 03 Aug 2023 17:02:03 -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 1qRfSM-0000oG-Nn for bug-gnu-emacs@gnu.org; Thu, 03 Aug 2023 17:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qRfSM-00012C-8R for bug-gnu-emacs@gnu.org; Thu, 03 Aug 2023 17:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Aug 2023 21:02: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.16910964693914 (code B ref 65017); Thu, 03 Aug 2023 21:02:02 +0000 Original-Received: (at 65017) by debbugs.gnu.org; 3 Aug 2023 21:01:09 +0000 Original-Received: from localhost ([127.0.0.1]:53029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRfRU-000112-Jg for submit@debbugs.gnu.org; Thu, 03 Aug 2023 17:01:08 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRfRQ-00010N-Bx for 65017@debbugs.gnu.org; Thu, 03 Aug 2023 17:01:07 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7795F1000EF; Thu, 3 Aug 2023 17:00:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1691096457; bh=bLG+mhWE4QciDptmIrcjTZEQGQsPZa/2q0yXyfc3M8s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FASSbYfp07Fh+4Lhi6iMFnZIs3Jk3NXzBqUCDkZB04aRbrHqPCqmRj2whHfQi02WC D6jIUH1UAXSK16svuFbk5h2/7aq4ywHI66B46ZBWBRsyciENar6eauEjHGZY21SccF c3WqCoV0W7pImph5wdhwkHB2Lo31GAzM3Cnmb2hm3+C9x6cqj2qJtzfHZFnaac0kgY q+vTOw+DbG2FR/wqu9+xQWMYv7nSE6EAwNC4wKARPoCBInwrEl+qP0iiGtLD7wOrA/ SQ3HXLxRke9o/xxNB6/3xjIGuniqI8OxVkqgYBN1N/8/XlqcXRhKGk2rwlYOoDtvVm KYhzBYBA6pDJA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 33DFC1000BC; Thu, 3 Aug 2023 17:00:57 -0400 (EDT) Original-Received: from alfajor (unknown [181.44.118.150]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 04BFE12034F; Thu, 3 Aug 2023 17:00:55 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Thu, 3 Aug 2023 18:22:30 +0000") 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:266623 Archived-At: >> That's a side problem. If absolutely needed, we could add some ad-hoc >> invalidation to work around the core problem, but I'd rather fix the >> core problem. > > Are you sure? Yes. > What is the core problem? The core problem is that we want to stop infinite macroexpansion of the same term. I.e. we want to stop macroexpansion from turning (function FOO) => (function FOO) => (function FOO) => ... so we tweak the macro-expander for `function` so that if FOO is exaction the same as last time, we return the exact list (function FOO) we built last time, rather than building a new one. If `eq` works as god intended (i.e. it performs a pointer-equality test), then this is perfectly safe because the cache always has the form (#1= . (function #1#)) so using the `cdr` of the cache returns something perfectly equivalent to `(function ,f) just with the added twist that it's the exact same list we return last time so may stop the macroexpansion. So it's safe the use the cache even when it's stale. But with `symbols-with-pos-enabled` the `eq` test can end up using the cache when FOO is not 100% the same as and so we can end up replacing `equal` or # with (function #) neither of which is really correct, the second of which can happen even if we try and flush the cache. > As I see it, if the function cl--labels-convert is called during byte > compilation, cl--labels-convert-cache is going to get symbols with > position. This is expected and is what we want - such a symbol might > easily give the position element of an error occurring in expanded code. Exactly, which is why the `eq` needs to pay attention to the position information. > So why would it not be a complete bug fix to initialise this variable > to nil at the start of every cl-flet or cl-labels? Because it could/would still replace some sympos with others within the same `cl-label`. Stefan