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.bugs Subject: bug#53526: 29.0.50; macroexp-warn-and-return API change Date: Tue, 25 Jan 2022 18:16:56 +0000 Message-ID: References: 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="4621"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53526@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 25 19:18:19 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1nCQOZ-0000xw-GJ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 25 Jan 2022 19:18:19 +0100 Original-Received: from localhost ([::1]:36748 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCQOY-00081s-5w for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 25 Jan 2022 13:18:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36526) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCQOJ-00080a-OZ for bug-gnu-emacs@gnu.org; Tue, 25 Jan 2022 13:18:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57132) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nCQOI-0006vJ-IH for bug-gnu-emacs@gnu.org; Tue, 25 Jan 2022 13:18:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nCQOI-0005e6-EV for bug-gnu-emacs@gnu.org; Tue, 25 Jan 2022 13:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Jan 2022 18:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53526 X-GNU-PR-Package: emacs Original-Received: via spool by 53526-submit@debbugs.gnu.org id=B53526.164313462721614 (code B ref 53526); Tue, 25 Jan 2022 18:18:02 +0000 Original-Received: (at 53526) by debbugs.gnu.org; 25 Jan 2022 18:17:07 +0000 Original-Received: from localhost ([127.0.0.1]:50030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCQNP-0005cY-DB for submit@debbugs.gnu.org; Tue, 25 Jan 2022 13:17:07 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:23147 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nCQNM-0005bw-8q for 53526@debbugs.gnu.org; Tue, 25 Jan 2022 13:17:06 -0500 Original-Received: (qmail 83171 invoked by uid 3782); 25 Jan 2022 18:16:57 -0000 Original-Received: from acm.muc.de (p4fe1523e.dip0.t-ipconnect.de [79.225.82.62]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 25 Jan 2022 19:16:57 +0100 Original-Received: (qmail 4779 invoked by uid 1000); 25 Jan 2022 18:16:56 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:225210 Archived-At: Hello, Stefan. On Tue, Jan 25, 2022 at 11:56:22 -0500, Stefan Monnier wrote: > Package: Emacs > Version: 29.0.50 > The following change in `macroexp.el` on `master` is not backward > compatible with the Emacs-28 API: > -(defun macroexp-warn-and-return (msg form &optional category compile-only) > +(defun macroexp-warn-and-return (arg msg form &optional category compile-only) No, it isn't. All the uses of the function are in lisp/emacs-lisp, and I understood the function to be an internal one. > I suspect that the `arg` should be added at the end instead. The other functions (like byte-compile-warn-x) which have acquired this extra argument need to have it at the start, since there are an indeterminate number of &rest args going into a `format'. So it seemed better just to do the same with this function, to preserve a sort of compatibility. > While I'm here I also noticed that `byte-compile-form-stack` is a poor > name for a variable declared in `macroexp.el`. It's an integral part of bytecomp.el. It got moved to macroexp.el because it is used (twice) there, and that file is loaded into bootstrap emacs before bytecomp.el. There is precedent for this "mis"naming, namely byte-compile-bound-variables. > It should either be renamed to use the `macroexp-` prefix, or moved to > `bytecomp.el` (and it probably should have a double-hyphen, since I > think it's not meant to be used by anyone but us). It started off life with a double hyphen in bytecomp.el. But when it started getting used in macroexp.el (during the expansion of a macro) it lost the extra hyphen and got moved there. It's no big deal, I think, just that there's no completely neat way of doing this, so the compromise actually used is pretty arbitrary. If the variable were in bytecomp.el, we'd probably need a boundp call in the two places we use it in macroexp.el. Whilst on the topic of macroexp-warn-and-return (and macroexp--wrap-warn), I have to admit having difficulty understanding these functions, both how they work and what they're for. My impression up till a couple of days ago was that they were ways of coping with the old warning position mechanism, and were intended to compensate for its deficiencies. Now, I'm much less sure. Was I indeed mistaken? If I was, what then is the purpose of these functions, which defer warning messages in some fashion? If I was right, it would be a good thing to dismantle them, since they are complicated and difficult, and no longer needed. As I said, I don't really understand them. Thanks! > Stefan -- Alan Mackenzie (Nuremberg, Germany).