unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: How to cause a compiler warning?
Date: Wed, 17 Jan 2024 11:59:29 +0000	[thread overview]
Message-ID: <ZafBIdh_ZJXKr4Xn@ACM> (raw)
In-Reply-To: <E1rPwc3-0000si-Cr@fencepost.gnu.org>

Hello, Richard.

On Tue, Jan 16, 2024 at 22:29:11 -0500, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

[ .... ]

>   > > > Since 29.1, the correct function for a warning has been
>   > > > byte-compile-warn-x.

>   > > What about `macroexp-warn-and-return'?

>   > It is a complicated way of calling byte-compile-warn-x.

> Since the warning would come from expansion of the cond* macro, I get
> the impression from the doc string that `macroexp-warn-and-return' MAY
> be exactly what I want.  But I can't be quite sure.

I've never really understood macroexp-warn-and-return either.  Its doc
string "Return code equivalent to FORM labeled with warning MSG." is
unhelpful, it being unclear precisely what "equivalent to" and "labeled
with" mean.

macroexp-warn-and-return expands FORM, attaching a call to
byte-compile-warn-x to it, somehow.  There's no documentation of it in
the Elisp manual, so the only way really to understand what it does is by
reading the source code.  But the ARG argument has the same meaning as
ARG in byte-compile-warn-x.

I think Ihor may well understand it, and Stefan Monnier (who wrote it)
certainly does.

My impression is that macroexp-warn-and-return is indeed what you want.

> `byte-compile-warn-x' has a feature of an argument (unhelpfully named ARG)
> which says, 
>     ARG is the source element (likely a symbol with position) central to
>       the warning, intended to supply source position information.

ARG can actually be any Lisp form at all.  Only when it is a symbol with
position, does it supply the source code location for the warning.  When
it is anything else, the location is taken from the most nested element
which is a symbol with position from a stack of forms.

I cannot see how it could be more helpfully named, but am open to
suggestions.

> Does `macroexp-warn-and-return' have a similar feature?

The last &optional parameter ARG has the same meaning, so yes.

> Does it use FORM for that?  If so, it woukd be helpful for its doc
> string to say FORM will be used this way.  With the current doc string
> it is not clear what it WILL do with FORM.

Yes, it uses FORM for that if ARG is not provided.  The doc string does
say this.

> Can someone please clarify these minor points so I can tell what to do?

> Also, it would be good to rename the argument ARG and improve the doc string
> as described above.

> -- 
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)

-- 
Alan Mackenzie (Nuremberg, Germany).



      reply	other threads:[~2024-01-17 11:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-14  3:09 How to cause a compiler warning? Richard Stallman
2024-01-14  3:20 ` João Távora
2024-01-14 13:01   ` Alan Mackenzie
2024-01-14 15:43     ` João Távora
2024-01-14 16:21       ` Alan Mackenzie
2024-01-15  0:16         ` João Távora
2024-01-17 12:25           ` Alan Mackenzie
2024-01-17 13:40             ` João Távora
2024-01-18 12:05               ` Alan Mackenzie
2024-01-18 12:26                 ` João Távora
2024-01-14 15:54     ` Ihor Radchenko
2024-01-14 16:26       ` Alan Mackenzie
2024-01-17  3:29         ` Richard Stallman
2024-01-17 11:59           ` Alan Mackenzie [this message]

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=ZafBIdh_ZJXKr4Xn@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /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).