GNU bug report logs - #13814
24.3.50; Dynamic variables shadowing prevent defvar

Previous Next

Package: emacs;

Reported by: Jorgen Schaefer <forcer <at> forcix.cx>

Date: Mon, 25 Feb 2013 20:37:01 UTC

Severity: normal

Tags: confirmed, moreinfo

Found in version 24.3.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #21 received at 13814 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 13814 <at> debbugs.gnu.org, Jorgen Schaefer <forcer <at> forcix.cx>
Subject: Re: bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
Date: Tue, 24 Aug 2021 17:25:33 -0400
Lars Ingebrigtsen [2021-08-23 03:21:26] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Thanks for filing it, so we have a clear bug-number for this long
>> standing problem.  If someone wants to take a crack at fixing it,
>> I think that we should add a `set-toplevel-default' which defvar and
>> defcustom could use, as for how to implement it, I you can take a look
>> at the check&warning in the C code of `defvar'.

FWIW, this bug was presumably fixed with:

    commit a104f656c8217b027866d32e8d7bf024a671e3cc
    Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
    Date:   Fri Aug 2 17:16:33 2013 -0400

So we should probably close it.

> When running this from M-: now, I get the following backtrace:
>
> Debugger entered--Lisp error: (error "Defining as dynamic an already lexical var")
>   (defvar bug-variable t "This variable is not defined when autoloaded.")
>   eval-buffer(#<buffer  *load*> nil "/tmp/bug-lib.el" nil t)  ; Reading at buffer position 74
>   load-with-code-conversion("/tmp/bug-lib.el" "/tmp/bug-lib.el" nil t)
>   (bug-variable-value)
>   (let ((bug-variable nil)) (bug-variable-value))
>   eval((let ((bug-variable nil)) (bug-variable-value)) t)
>   eval-expression((let ((bug-variable nil)) (bug-variable-value)) nil nil 127)
>   funcall-interactively(eval-expression (let ((bug-variable nil)) (bug-variable-value)) nil nil 127)
>   call-interactively(eval-expression nil nil)
>
> So this signals an error when doing the
>
> (let ((bug-variable nil))
>   (bug-variable-value))
>
> from a lexical context.

Yes, this is a new feature: when we get to the `defvar` the problem is
not just that we need to "punch through" and define the toplevel/dynamic
value of `bug-variable` but also that the `let` would need to be
retroactively changed to be dynamic, which would in general require
time-travel, hence the error.

The fix is to use another var name (if you do want your `let` to be
statically scoped) or to use `dlet`, or an explicit `defvar`, or an
explicit `(require 'bug-lib)`, ...


        Stefan





This bug report was last modified 3 years and 273 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.