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: 73746@debbugs.gnu.org, acm@muc.de,
	"Mattias Engdegård" <mattias.engdegard@gmail.com>,
	73725@debbugs.gnu.org
Subject: bug#73725: Master: Wrong position for byte compiler warning message.
Date: Tue, 22 Oct 2024 21:19:13 +0000	[thread overview]
Message-ID: <ZxgW0YjpLqlgndcI@MAC.fritz.box> (raw)
In-Reply-To: <jwv5xpk47d3.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Tue, Oct 22, 2024 at 09:33:02 -0400, Stefan Monnier wrote:

[ .... ]

> >> >  (defun macroexp-macroexpand (form env)
> >> >    "Like `macroexpand' but checking obsolescence."
> >> >    (let* ((macroexpand-all-environment env)
> >> >           new-form)
> >> > +    (macroexp-preserve-posification
> >> > +     form
> >> >      (while (not (eq form (setq new-form (macroexpand-1 form env))))
> >> > +       (setq macroexpanded t)
> >> >        (let ((fun (car-safe form)))
> >> >          (setq form
> >> >                (if (and fun (symbolp fun)

> >> This `(setq macroexpanded t)` looks like some leftover code, at least
> >> I couldn't find this var declared or used elsewhere.

> > I remember removing it, but can't remember exactly why.  When I byte
> > compile the code, I don't get an undeclared variable warning for it, for
> > some reason.

> [ Interesting.  I'll try to remember to track down this sucker later.  ]

I think I understand this, now.  It's a "use-mention" confusion.  ;-).

When macroexp-macroexpand is getting compiled, the compiler calls (the
loaded or compiled version of) that function.  Running the function
`setq's macroexpanded, hence binds it.

Later, the compiler calls byte-compile-free-vars-warn.  This fails to do
anything because of the clause (boundp var) in the enclosing `unless'
form.  VAR aka macroexpanded is indeed now bound, see previous
paragraph.

I'm not sure there's much that can be done about this "bug".  I'm even
less sure that it's worth the trouble.  Maybe there could be a more
rigorous check of the variable's existence than (boundp var).  But, as I
say, it's likely not worth the trouble.  Maybe there are other free
variables hiding in the compiler, though.

What do you think?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2024-10-22 21:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-10 10:22 bug#73725: Master: Wrong position for byte compiler warning message Alan Mackenzie
2024-10-11 23:45 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-12 10:47   ` Alan Mackenzie
2024-10-12 13:53     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-12 12:01   ` Mattias Engdegård
2024-10-20 14:13     ` Alan Mackenzie
2024-10-20 15:06       ` Mattias Engdegård
2024-10-20 15:38         ` bug#73746: " Alan Mackenzie
2024-10-20 16:35       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-22 12:48         ` Alan Mackenzie
2024-10-22 13:33           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-22 21:19             ` Alan Mackenzie [this message]
2024-10-23 13:30               ` bug#73746: " Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-23 11:22             ` Alan Mackenzie
2024-10-23 13:27               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-23 17:44                 ` Alan Mackenzie
2024-10-23 17:49               ` Mattias Engdegård
2024-10-23 19:03                 ` Alan Mackenzie
2024-10-13 15:31   ` 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=ZxgW0YjpLqlgndcI@MAC.fritz.box \
    --to=acm@muc.de \
    --cc=73725@debbugs.gnu.org \
    --cc=73746@debbugs.gnu.org \
    --cc=mattias.engdegard@gmail.com \
    --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).