From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: How to cause a compiler warning? Date: Wed, 17 Jan 2024 12:25:22 +0000 Message-ID: References: <871qak4n4h.fsf@gmail.com> <87v87ve9i5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3189"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , emacs-devel To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 17 13:26:17 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rQ4zp-0000az-RZ for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Jan 2024 13:26:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQ4z7-0005rF-7x; Wed, 17 Jan 2024 07:25:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rQ4z2-0005o5-Au for emacs-devel@gnu.org; Wed, 17 Jan 2024 07:25:31 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rQ4z0-0007j1-BI for emacs-devel@gnu.org; Wed, 17 Jan 2024 07:25:28 -0500 Original-Received: (qmail 98857 invoked by uid 3782); 17 Jan 2024 13:25:23 +0100 Original-Received: from acm.muc.de (p4fe15520.dip0.t-ipconnect.de [79.225.85.32]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 17 Jan 2024 13:25:23 +0100 Original-Received: (qmail 7007 invoked by uid 1000); 17 Jan 2024 12:25:22 -0000 Content-Disposition: inline In-Reply-To: <87v87ve9i5.fsf@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315037 Archived-At: Hello, Joćo. On Mon, Jan 15, 2024 at 00:16:34 +0000, Joćo Tįvora wrote: > Alan Mackenzie 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).