From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: 73746@debbugs.gnu.org,
"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 09:33:02 -0400 [thread overview]
Message-ID: <jwv5xpk47d3.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <ZxefBoBT1hGRf08W@MAC.fritz.box> (Alan Mackenzie's message of "Tue, 22 Oct 2024 12:48:06 +0000")
>> Is this needed? I'd expect we need `macroexp-preserve-posification`
>> only at those places where an optimization returns a form whose `car` is
>> different from that of FORM. So I expect this to happen in more
>> specific places inside byte-opt.el than here.
> Yes, it is needed. byte-optimize-form-code-walker sometimes does return
> a form with a different car. For example, a progn form with a single
> sub-form comes back without the progn.
This should usually be harmless since the subform should come with its own
position information.
> Even if there are several sub-forms, the code uses macroexp-progn to
> substitute a different progn symbol without the position. I don't
> know why it does this.
This is more annoying, indeed. Ideally, we'd move the
`macroexp-preserve-posification` to the place(s) where this remove+readd
`progn` happens.
> One of my ideas was to fix byte-optimize-form-code-walker by fixing each
> individual bit where the SWP got lost. In the end I gave that up as too
> much work, and too difficult to test.
Hmm... I see. We can leave for a later optimization of
`byte-optimize-form-code-walker`.
>> IOW, this deserves a clear comment explaining why we need it here,
>> probably with some kind of example.
> OK, I'll put one in, along the lines of the above, but less wordy.
Thanks.
> Good point. The doc string of that function is a little clumsy, as it
> refers to the doc string of the next function macroexp--posify-form,
That part did not bother me. These are internal functions so it's OK if
the docstring is a bit less "self contained".
> But I'll write somewhere that we modify "a single symbol", or something
> like that.
Thanks.
>> > (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. ]
>> > -(defun macroexpand-all (form &optional environment)
>> > +(defun macroexpand-all (form &optional environment keep-pos)
>> Any reason why we need this new argument?
>> Can't we just always try to preserve the positions?
> There are lots of calls to macroexpand-all (around 37), and I was
> concerned about possible accidental side effects in these.
I think we should assume that those potential side effects would more
likely be beneficial than harmful.
Another way to look at it is to look at the doc you provided:
KEEP-POS, if non-nil, specifies that any symbol-with-position for
FORM should be preserved, later to be usable by
`byte-compile--warning-source-offset'.
Even when `keep-pos` is nil, `macroexpand-all` will preserve most of the
SWPs, so the doc is misleading.
> Also, always trying to preserve the position might slow down
> compilation, but I haven't measured that yet.
I think the calls where you currently ask for `keep-pos` account for the
vast majority of the time spent macro-expanding, so I'd be surprised if
doing it in all cases would make it measurably worse.
Stefan
next prev parent reply other threads:[~2024-10-22 13:33 UTC|newest]
Thread overview: 12+ 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 [this message]
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=jwv5xpk47d3.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=73725@debbugs.gnu.org \
--cc=73746@debbugs.gnu.org \
--cc=acm@muc.de \
--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).