emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to cause a compiler warning?


From: João Távora
Subject: Re: How to cause a compiler warning?
Date: Mon, 15 Jan 2024 00:16:34 +0000
User-agent: Gnus/5.13 (Gnus v5.13)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]