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 11:59:29 +0000 Message-ID: References: <871qak4n4h.fsf@gmail.com> <874jffsyfy.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32713"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 17 13:00:43 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 1rQ4b4-0008K4-Tg for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Jan 2024 13:00:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQ4aI-00042C-RL; Wed, 17 Jan 2024 06:59:56 -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 1rQ4a8-00041i-Tm for emacs-devel@gnu.org; Wed, 17 Jan 2024 06:59:46 -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 1rQ4a6-0001Bi-LV for emacs-devel@gnu.org; Wed, 17 Jan 2024 06:59:44 -0500 Original-Received: (qmail 67081 invoked by uid 3782); 17 Jan 2024 12:59:30 +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 12:59:30 +0100 Original-Received: (qmail 6878 invoked by uid 1000); 17 Jan 2024 11:59:29 -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=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:315035 Archived-At: 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).