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: Thu, 18 Jan 2024 12:05:33 +0000 Message-ID: References: <871qak4n4h.fsf@gmail.com> <87v87ve9i5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25020"; 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 Thu Jan 18 13:06:30 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 1rQRAE-0006Fo-39 for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Jan 2024 13:06:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQR9e-0002dh-Oq; Thu, 18 Jan 2024 07:05:55 -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 1rQR9Z-0002Xr-MJ for emacs-devel@gnu.org; Thu, 18 Jan 2024 07:05:49 -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 1rQR9X-0003Hz-TI for emacs-devel@gnu.org; Thu, 18 Jan 2024 07:05:49 -0500 Original-Received: (qmail 9029 invoked by uid 3782); 18 Jan 2024 13:05:34 +0100 Original-Received: from acm.muc.de (p4fe15fce.dip0.t-ipconnect.de [79.225.95.206]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 18 Jan 2024 13:05:33 +0100 Original-Received: (qmail 7347 invoked by uid 1000); 18 Jan 2024 12:05:33 -0000 Content-Disposition: inline In-Reply-To: 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=unavailable 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:315080 Archived-At: 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 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).