bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar

[Lars Ingebrigtsen]

Stefan Monnier <monnier@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'.

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.

And...  from a dynamic context, it seems like this works as it should
now?  That is, the defvar "punches through" the let binding and defines
the variable properly.  (Which I didn't know; last time I looked at
this, it didn't work, but it's some years back.)

Has this been fixed, or am I testing it wrong somehow?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no