unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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: "Mattias Engdegård" <mattias.engdegard@gmail.com>, 73725@debbugs.gnu.org
Subject: bug#73725: Master: Wrong position for byte compiler warning message.
Date: Sat, 12 Oct 2024 09:53:55 -0400	[thread overview]
Message-ID: <jwv7cadigcq.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <ZwpT2cqTwdUBldr3@MAC.fritz.box> (Alan Mackenzie's message of "Sat, 12 Oct 2024 10:47:53 +0000")

> I haven't, no.  It might well work.  But I think the `push' form should
> go outside of the loop,

Really?  I thought it made more sense to put it inside the loop, so
a macro X1 that expands to macro X2 ... will get all of the
corresponding locations pushed, thus preserving more of the info about
where things are coming from.

> I'm also a little wary about pushing an item onto stack when it
> doesn't get popped again after the form(s) it is "guarding".

The patch seemed like an easier way to describe the intent than trying
to phrase it in prose, but it's definitely not meant to be used as-is.
I agree that we need to make sure things get popped as needed (tho I got
the impression that it should indeed already occur (at least in the
call-path I looked at)).

>> If it doesn't work, do you happen to know why?
> I'm not sure whether it would work for the (similar) bug, bug#73746,
> where the symbols with position were getting lost in byte-opt.el.

Oh, indeed my patch won't work at all when the warning/error message is
emitted later on: we need to preserve the info in the macro-expanded
code itself rather than in the locations-info stack.


        Stefan






  reply	other threads:[~2024-10-12 13:53 UTC|newest]

Thread overview: 6+ 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 [this message]
2024-10-12 12:01   ` Mattias Engdegård
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=jwv7cadigcq.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=73725@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).