bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#59057: Emacs 29. Byte compiler sometimes forgets about a defvar.


From: Alan Mackenzie
Subject: bug#59057: Emacs 29. Byte compiler sometimes forgets about a defvar.
Date: Mon, 7 Nov 2022 20:20:20 +0000

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).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]