From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#46387: 28.0.50; Compiled code making a variable dynamic stopped working Date: Tue, 09 Feb 2021 13:48:50 -0500 Message-ID: References: <87h7mm79ij.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2853"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Michael Heerdegen , 46387@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 09 19:52:28 2021 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 1l9Y7g-0000fY-HB for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Feb 2021 19:52:28 +0100 Original-Received: from localhost ([::1]:56408 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9Y7f-0003PA-ET for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Feb 2021 13:52:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47536) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9Y5K-0000z2-9d for bug-gnu-emacs@gnu.org; Tue, 09 Feb 2021 13:50:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43071) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l9Y5J-0005gq-QG for bug-gnu-emacs@gnu.org; Tue, 09 Feb 2021 13:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l9Y5J-00024g-Ob for bug-gnu-emacs@gnu.org; Tue, 09 Feb 2021 13:50:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Feb 2021 18:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46387 X-GNU-PR-Package: emacs Original-Received: via spool by 46387-submit@debbugs.gnu.org id=B46387.16128965427905 (code B ref 46387); Tue, 09 Feb 2021 18:50:01 +0000 Original-Received: (at 46387) by debbugs.gnu.org; 9 Feb 2021 18:49:02 +0000 Original-Received: from localhost ([127.0.0.1]:54617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9Y4M-00023R-Gu for submit@debbugs.gnu.org; Tue, 09 Feb 2021 13:49:02 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53413) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9Y4L-00022x-8T for 46387@debbugs.gnu.org; Tue, 09 Feb 2021 13:49:02 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5CED21006F2; Tue, 9 Feb 2021 13:48:55 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9E6671000CF; Tue, 9 Feb 2021 13:48:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1612896531; bh=KFAE/lz3zYx/un0low9INj1wYYEWIx3hNxWKM11797k=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Jm/OwwhgsLi+TOPdhLvCMdOZTEf8fK8Ssmwov5G1QldYJyfEoLtpDjq7t5Llw9XoD nwG4TMP36hAmDv6SvHqpADDui69MTxqNHjoZSQG7GvdZxyWbYjh3OYncwq5w/xZWn6 PtiEWERLY1xUPYXC/1WY0YT9rJk8gm2TkYTxMpKCmm0ZxCyh457X3JWLc8c6Ttt7m2 KKYVPfPiZnEjLXWFYYc5kDzP5gEpa5FEJkHjEofu9pwp6dIcBBgsYt6PLYM0tAzHRR FtSbTXh4qmj0/Ydvh0k78OsqoGwbgAcfZHIoor7YzL3jC/Dl8R5O2X27UbY9RBek7s Dl/ZynjlX5KNg== Original-Received: from alfajor (unknown [216.154.41.47]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 75E47120297; Tue, 9 Feb 2021 13:48:51 -0500 (EST) In-Reply-To: ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Tue, 9 Feb 2021 17:49:20 +0100") 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" Xref: news.gmane.io gmane.emacs.bugs:199718 Archived-At: >> Adding a variable to the context creates a new scope. >> A `progn` should not introduce a new scope. > > All right, `defvar` modifies the current scope and only let, let* and > lambda create new scopes. Fine, but it leaves questions unanswered. Oh, yes. > * Does `defvar` affect new bindings only, or variable references in the current scope as well? Subsequent bindings. > (let ((my-var EXPR)) > (defvar my-var) > (use my-var)) `defvar` here is "too late" to affect the earlier `let`. > does the last line refer to the lexical my-var bound in the first > line, or to the dynamic my-var? If there's a lexical var in scope with the right name, that's what is used, regardless if the variable is (currently) declared as dynamically scoped or not. E.g. (funcall (lambda (default-directory) (cd "/") default-directory) 3) returns 3 (in `lexical-binding` mode). > * Does the defvar have to be 'executed' to be effective? That's how > the interpreter works, but it clearly can't work in the compiler. Your (if foo (defvar bar)) example indeed points to some of the other murkiness, where the behavior differs between the interpreter and the compiler, yes. If it hurts, don't do that ;-) > The defvar form probably has to 'precede' the binding form which it > tries to affect, in some way. A `defvar` should be effective on all subsequent equally or more deeply-nested code. Whether it also affects other subsequent code is the less clear part. `progn` (and macros to expand to `progn`, of course) is the only "sure" exception (i.e. a `defvar` also affects the code after its surrounding `progn`, if any). >> The (with-suppressed-warnings (...) (defvar)) form is used at >> several places. It's the preferred way to declare a variable >> dynamically scoped without incurring the "not prefixed" warning and >> without making the `with-suppressed-warnings` silencer cover more code >> than intended. > Yes, but it does (currently) work if used on a single variable at a time, > which is the suggested workaround for the time being. It's better than nothing, but I think we really should fix the `progn` case, because it's important. Stefan