How to cause a compiler warning?

How to cause a compiler warning?

[Richard Stallman]

[[[ 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. ]]]

I would like to make the cond* macro generate warnings in certain
cases, when it is being copiled.  What is the recommended way to do
that?

When I implemented constrained variables, nested constrained variables
simply worked, with no extra code.  But since some people said they were
confusing, I am thinking of issuing a warning for those cases.

-- 
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)

Re: How to cause a compiler warning?

[João Távora]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
> I would like to make the cond* macro generate warnings in certain
> cases, when it is being copiled.  What is the recommended way to do
> that?

Probably call byte-compile-warn at macro-expansion time?

Re: How to cause a compiler warning?

[Alan Mackenzie]

Hello, João.

On Sun, Jan 14, 2024 at 03:20:14 +0000, João Távora wrote:
> Richard Stallman <rms@gnu.org> writes:

> > [[[ 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. ]]]
> >
> > I would like to make the cond* macro generate warnings in certain
> > cases, when it is being copiled.  What is the recommended way to do
> > that?

> Probably call byte-compile-warn at macro-expansion time?

Most assuredly not.  This may give an incorrect file position for the
warning.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: How to cause a compiler warning?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On Sun, Jan 14, 2024, 13:01 Alan Mackenzie <acm@muc.de> wrote:

>
> > > I would like to make the cond* macro generate warnings in certain
> > > cases, when it is being copiled.  What is the recommended way to do
> > > that?
>
> > Probably call byte-compile-warn at macro-expansion time?
>
> Most assuredly not.  This may give an incorrect file position for the
> warning.
>

Aight, I wasnt thaaat far off the mark..

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

Self-evidently so, of course, the 'x' standing for "correct". Anyway, what
about <29 compatible code?

João

>

[-- Attachment #2: Type: text/html, Size: 1426 bytes --]

Re: How to cause a compiler warning?

[Alan Mackenzie]

Hello, João.

On Sun, Jan 14, 2024 at 15:43:51 +0000, João Távora wrote:
>    On Sun, Jan 14, 2024, 13:01 Alan Mackenzie <[1]acm@muc.de> wrote:

>      > > I would like to make the cond* macro generate warnings in
>      certain
>      > > cases, when it is being copiled.  What is the recommended way
>      to do
>      > > that?
>      > Probably call byte-compile-warn at macro-expansion time?
>      Most assuredly not.  This may give an incorrect file position for
>      the
>      warning.

>    Aight, I wasnt thaaat far off the mark..

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

>    Self-evidently so, of course, the 'x' standing for "correct".

Something like that, yes.

>    Anyway, what about <29 compatible code?

What about it?  Richard isn't working on < 29 code at the moment.

>    João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: How to cause a compiler warning?

[João Távora]

Alan Mackenzie <acm@muc.de> writes:

>>      Most assuredly not.  This may give an incorrect file position for
>>      the
>>      warning.
> ...
>>      Since 29.1, the correct function for a warning has been
>>      byte-compile-warn-x.
>
>>    Self-evidently so, of course, the 'x' standing for "correct".
>
> Something like that, yes.

I've had a better look at the 'byte-compile-warn-x' helper.  I think I
understand what it does, but the docstring leaves to be desired, it says
the first argument a "source element, likely a symbol with position",
which is vague and curious nomenclature I've not seen in other Lisps.

More importantly, is there always a "source element" to give to
byte-compile-warn-x?  Doesn't it depend on the case?

Many macros operate on Lisp forms and sometimes there is some obvious
good form to hook onto and presumably this form is either is a
sym-with-pos or has some such symbols inside it.  Like this:

(defmacro fooing (a &rest body)
  (when (eq (car-safe a) 'quote)
    (byte-compile-warn-x a "don't quote me, silly"))
  ...)

Here, I do agree 'byte-compile-warn-x' is much better than
'byte-compile-warn', as Flymake highlights exactly the symbol in that
position.  Great.

But macros are also just functions and sometimes they need to warn
because... it's Wednesday or something.

(defmacro define-foos (howmanyfoos)
  (when (its-wednesday)
    (byte-compile-warn "Beware code compiled on wednesdays!"))
  ...)

Here, 'byte-compile-warn', which makes the whole 'define-foos'
highlighted by Flymake is not only perfectly valid but also the only
viable option.

So I don't think byte-compiler-warn-x is "most assuredly" the only util
you should use.  If it were, byte-compiler-warn might as well be
deprecated.

>>    Anyway, what about <29 compatible code?
>
> What about it?  Richard isn't working on < 29 code at the moment.

Alright, but since you were so assertive in overriding my suggestion
with a fairly new util, maybe you could comment on what to do in code
intended to work in those versions, for the benefit of others.

João

Re: How to cause a compiler warning?

[Alan Mackenzie]

Hello, João.

On Mon, Jan 15, 2024 at 00:16:34 +0000, João Távora wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >>      Most assuredly not.  This may give an incorrect file position for
> >>      the
> >>      warning.
> > ...
> >>      Since 29.1, the correct function for a warning has been
> >>      byte-compile-warn-x.

> >>    Self-evidently so, of course, the 'x' standing for "correct".

> > Something like that, yes.

> I've had a better look at the 'byte-compile-warn-x' helper.  I think I
> understand what it does, but the docstring leaves to be desired, it says
> the first argument a "source element, likely a symbol with position",
> which is vague and curious nomenclature I've not seen in other Lisps.

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

> More importantly, is there always a "source element" to give to
> byte-compile-warn-x?  Doesn't it depend on the case?

In practice, there is almost always such a source element, yes.  In
those rare cases (I can't think of any at the moment) where there is
not, putting in a nil would work, the source code position then being
taken from byte-compile-form-stack.

> Many macros operate on Lisp forms and sometimes there is some obvious
> good form to hook onto and presumably this form is either is a
> sym-with-pos or has some such symbols inside it.  Like this:

> (defmacro fooing (a &rest body)
>   (when (eq (car-safe a) 'quote)
>     (byte-compile-warn-x a "don't quote me, silly"))
>   ...)

> Here, I do agree 'byte-compile-warn-x' is much better than
> 'byte-compile-warn', as Flymake highlights exactly the symbol in that
> position.  Great.

> But macros are also just functions and sometimes they need to warn
> because... it's Wednesday or something.

> (defmacro define-foos (howmanyfoos)
>   (when (its-wednesday)
>     (byte-compile-warn "Beware code compiled on wednesdays!"))
>   ...)

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.

> Here, 'byte-compile-warn', which makes the whole 'define-foos'
> highlighted by Flymake is not only perfectly valid but also the only
> viable option.

> So I don't think byte-compiler-warn-x is "most assuredly" the only util
> you should use.  If it were, byte-compiler-warn might as well be
> deprecated.

Yes, deprecating byte-compile-warn would be a good thing to do, thanks.

> >>    Anyway, what about <29 compatible code?

> > What about it?  Richard isn't working on < 29 code at the moment.

> Alright, but since you were so assertive in overriding my suggestion
> with a fairly new util, maybe you could comment on what to do in code
> intended to work in those versions, for the benefit of others.

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.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: How to cause a compiler warning?

[João Távora]

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.

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.

> source code locations are annoying in the extreme.

That's a bit of an extreme statement.

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.

> 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.  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.

My point is you shouldn't make this a hard rule with such dogmatism
But it was fine to suggest byte-compile-warn-x, which I didn't
know about, so thanks.

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).

Re: How to cause a compiler warning?

[João Távora]

On Thu, Jan 18, 2024 at 12:05 PM Alan Mackenzie <acm@muc.de> wrote:

> > 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.

FORM is the nomenclature given to Lisp objects that represent
symbolic expressions: it's not an exclusive of the byte compiler.
Appears in very many numerous places in our Emacs,
just grep for it.

> 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?

Turn on M-x flymake-mode in an Elisp buffer and introduce a mistake
(be careful though, it compiles as you type, and that runs code).

> You haven't identified a concrete case where byte-compile-warn-x would
> be inappropriate, or difficult to use.

I have, of course. Sometimes there's no form to give it, or you don't
want to choose a particular one form to hook the warning on to.

Passing nil is fine, I guess, but a bit awkward.  If you ask me,
byte-compile-warn should have been kept and an additional
optional arg added.  Even a keyword arg! Oh noes!

Anyway, I don't have much more to add.
João

Re: How to cause a compiler warning?

[Ihor Radchenko]

Alan Mackenzie <acm@muc.de> writes:

>> > I would like to make the cond* macro generate warnings in certain
>> > cases, when it is being copiled.  What is the recommended way to do
>> > that?
>
>> Probably call byte-compile-warn at macro-expansion time?
>
> Most assuredly not.  This may give an incorrect file position for the
> warning.
>
> Since 29.1, the correct function for a warning has been
> byte-compile-warn-x.

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

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: How to cause a compiler warning?

[Alan Mackenzie]

Hello, Ihor.

On Sun, Jan 14, 2024 at 15:54:09 +0000, Ihor Radchenko wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> > I would like to make the cond* macro generate warnings in certain
> >> > cases, when it is being copiled.  What is the recommended way to do
> >> > that?

> >> Probably call byte-compile-warn at macro-expansion time?

> > Most assuredly not.  This may give an incorrect file position for the
> > warning.

> > 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.

It probably isn't of interest to Richard at this stage.

> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: How to cause a compiler warning?

[Richard Stallman]

[[[ 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. ]]]

Thanks to all those who have posted answers.  I've removed all
but one of you (the one this is a direct reply to) from the CC
so you won't get two copies.

  > > > 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* pacro, I get
the impression from the doc string that `macroexp-warn-and-return' MAY
be exactly what I want.  But I can't br quite sure.

`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.

Does `macroexp-warn-and-return' have a similar feature?  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.

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)

Re: How to cause a compiler warning?

[Alan Mackenzie]

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).