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#59057: Emacs 29. Byte compiler sometimes forgets about a defvar. Date: Mon, 7 Nov 2022 20:20:20 +0000 Message-ID: References: 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="3799"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59057@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 07 21:21:24 2022 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 1os8cW-0000ny-NS for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 07 Nov 2022 21:21:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1os8cM-0003Jb-AM; Mon, 07 Nov 2022 15:21:15 -0500 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 1os8cC-0003IF-Lu for bug-gnu-emacs@gnu.org; Mon, 07 Nov 2022 15:21:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1os8cA-0005gx-1Z for bug-gnu-emacs@gnu.org; Mon, 07 Nov 2022 15:21:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1os8c9-0006xz-Jy for bug-gnu-emacs@gnu.org; Mon, 07 Nov 2022 15:21:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Nov 2022 20:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59057 X-GNU-PR-Package: emacs Original-Received: via spool by 59057-submit@debbugs.gnu.org id=B59057.166785243126732 (code B ref 59057); Mon, 07 Nov 2022 20:21:01 +0000 Original-Received: (at 59057) by debbugs.gnu.org; 7 Nov 2022 20:20:31 +0000 Original-Received: from localhost ([127.0.0.1]:35494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1os8be-0006x5-HR for submit@debbugs.gnu.org; Mon, 07 Nov 2022 15:20:30 -0500 Original-Received: from mx3.muc.de ([193.149.48.5]:37949) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1os8bc-0006wn-S5 for 59057@debbugs.gnu.org; Mon, 07 Nov 2022 15:20:29 -0500 Original-Received: (qmail 21687 invoked by uid 3782); 7 Nov 2022 21:20:20 +0100 Original-Received: from acm.muc.de (p4fe15967.dip0.t-ipconnect.de [79.225.89.103]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 07 Nov 2022 21:20:20 +0100 Original-Received: (qmail 17820 invoked by uid 1000); 7 Nov 2022 20:20:20 -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:247297 Archived-At: Hello, Stefan. On Mon, Nov 07, 2022 at 08:07:28 -0500, Stefan Monnier wrote: > > (defmacro acm-defvar (var) > > `(eval-when-compile > > ; (when (version-check) > > (defvar ,var) > > (setq ,var emacs-major-version) > > ; ) > > )) > (defvar VAR) does not "create a variable". According to both its doc string and the Elisp manual it does. > It just "locally" declares that this identifier should use dynamic > scoping when binding a variable. Why "locally"? There's just one obarray involved, which is global. The manual says that, with defun, "The variable is marked as "special", meaning that it should always be dynamically bound.". In my example program, l-s-p was created with defvar, yet later in the example, the compiler bound it lexically. There is a bug here, either in the code or in the documentation. > Before the commit you mentioned, the above (defvar ,var) would sometimes > incorrectly escape its `when` subexpression and affect subsequent code, > which is why in the past the presence of `when` did not make much > difference whereas it now does. What was incorrect about this "escaping"? It would appear to match the elisp manual, and its effect on subsequent code would be positive, rather than negative, surely? Why does the `when' now prevent l-s-p being marked as global? In particular, why is it not entered into the list byte-compile-bound-variables? > Note also that for the same reason the above should arguably never work > at all since the effect of (defvar ,var) should not escape the > `eval-when-compile` subexpression. Why shouldn't it? The defvar is evaluated at compilation time, should create l-s-p, and should mark it as dynamically bound. It does in fact create the variable (see `message' output), but doesn't mark it as dynamic when the evaluation is inside a conditional. > A lot of code relies on this misbehavior, tho, so we still support it. By what criterion is it "misbehaviour"? It would appear to be what defvar's doc string and manual entry say. > But the better way to write the above code is: > (defmacro acm-defvar (var) > `(progn > (defvar ,var) > (eval-when-compile > (when (version-check) > (setq ,var emacs-major-version))))) There are workarounds, yes. But surely it would be better to fix the bug. > > This bug doesn't occur on Emacs 28. > > I have a feeling it was introduced into Emacs 29 very recently. > The Emacs-28 behavior was a misbehavior, which got fixed accidentally > recently :-) I feel I'm beginning to get repetitive here. ;-) But what was incorrect about the Emacs 28 behaviour? The current behaviour causes confusing, incorrect warning messages to get output. It cost me many hours of labour till I finally found out the warnings came from a change in the byte compiler. Surely either the code or the documentation should be fixed, so that other people don't have to go through the same. > Stefan -- Alan Mackenzie (Nuremberg, Germany).