unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 59057@debbugs.gnu.org
Subject: bug#59057: Emacs 29. Byte compiler sometimes forgets about a defvar.
Date: Mon, 7 Nov 2022 20:20:20 +0000	[thread overview]
Message-ID: <Y2lohC66d/uSi5oz@ACM> (raw)
In-Reply-To: <jwvsfiux6so.fsf-monnier+emacs@gnu.org>

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	other threads:[~2022-11-07 20:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-05 18:46 bug#59057: Emacs 29. Byte compiler sometimes forgets about a defvar Alan Mackenzie
2022-11-07 13:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-07 20:20   ` Alan Mackenzie [this message]
2022-11-07 21:29     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-08 11:01       ` Alan Mackenzie
2022-11-08 14:12         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-07 21:31     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-09 13:40       ` Alan Mackenzie
2022-11-09 17:54         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-24 19:29           ` Stefan Kangas
2022-11-24 19:33             ` Eli Zaretskii
2022-11-24 20:36             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-24 21:12               ` Stefan Kangas
2022-11-25 10:36                 ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y2lohC66d/uSi5oz@ACM \
    --to=acm@muc.de \
    --cc=59057@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).