Re: How to cause a compiler warning?

[Alan Mackenzie]

Hello, João.

On Wed, Jan 17, 2024 at 13:40:04 +0000, João Távora wrote:
> On Wed, Jan 17, 2024 at 12:25 PM Alan Mackenzie <acm@muc.de> wrote:

> > ARG can be any Lisp form at all.  How would you reformulate the doc
> > string to make it less vague and curious?

> Call it FORM.  Then add in the text you wrote to Richard, who
> seem to have also been confused.

FORM is unsuitable, because in the byte compiler it always means the
form currently being compiled.  Besides in macroexp-warn-and-return,
there's already a parameter called FORM.

Maybe POS would do.  But that could mislead people into giving a number
rather than a symbol with position.

> I got the idea of it pretty quickly, even with the ARG naming,
> so take that as a data point.

> > Really?  Can you point out any such existing macro in the source files
> > of the byte compiler?  You must be aware that warning messages without
> > source code locations are annoying in the extreme.

> Not all macros process forms.  Just search for a macro without arguments.

Hmmm.

> > source code locations are annoying in the extreme.

> That's a bit of an extreme statement.

I don't think so.  A workflow so prevalent as to count as universal is
to compile a .el file, look at the list of warnings and to jump to the
source position of each warning and fix it.  A warning without a
position (or a wrong position) blocks this workflow.

> Macros that don't process source code and are used simply to
> generate Lisp code don't have anything else to report. So using
> byte-compiler-warn is fine and you'll see the macro invocation
> itself highlighted.

What do you mean, "you'll see the macro invocation itself highlighted"?
You certainly won't in a batch compilation, and I don't recall seeing
anything highlighted anywhere for a compilation from within a running
Emacs.  In which window would this highlighting appear?

If such a macro does generate a warning, it should give as position a
symbol in its own code to direct the user to the location which needs
fixing.  byte-compile-warn is not fine; it doesn't give any location.

> > byte-compile-warn-x is intended for use in the byte compiler.  Anybody
> > doing work there should be sophisticated enough to understand what to
> > do.  In macros which extend the Lisp language, there is
> > macroexp-warn-and-return, for anybody who can understand it.  Do people
> > actually write such language extensions and expect them to work on old
> > Emacs versions?  There may be, but I'm not aware of any.

> I write macros that are supposed to work back to Emacs 26 yes.

That doesn't address my question.  I was asking about macros WHICH
EXTEND THE LISP LANGUAGE.  Things like pcase, or Richard's new cond*.

> I frequently don't bother with byte-compiler-errors as I tend to let
> the other macros and special forms my macro expands to do that.  But
> not necessarily always.

Why are you using the byte compiler warning functions anyway?  Some of
the time, these macros will be interpreted, not compiled, so these
functions are thus inappropriate.  byte-compile-warn-x is for the use of
the byte compiler.

> My point is you shouldn't make this a hard rule with such dogmatism.

You haven't convinced me.  byte-compile-warn is obsolete and has been
superseded.  It gives no position information.  Before Emacs 29, it used
to try to give position info, which it frequently got wrong.

You haven't identified a concrete case where byte-compile-warn-x would
be inappropriate, or difficult to use.  If it's a matter of backward
compatibility, then something in that compatibility library (whose name
I can't remember) would seem to be the thing.

> But it was fine to suggest byte-compile-warn-x, which I didn't
> know about, so thanks.

My pleasure!

-- 
Alan Mackenzie (Nuremberg, Germany).