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#67483: Wrong warning position given by the byte compiler for a malformed function Date: Fri, 22 Dec 2023 11:24:26 +0000 Message-ID: References: <59773797-CC64-4352-9528-4E7593DD3C1F@gmail.com> <522B6349-614D-48AD-963D-76CF59A30497@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="32876"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, Stefan Monnier , 67483@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 22 12:25:18 2023 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 1rGdeY-0008IK-PB for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Dec 2023 12:25:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rGdeF-0008I8-Va; Fri, 22 Dec 2023 06:25:00 -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 1rGdeE-0008Hj-8v for bug-gnu-emacs@gnu.org; Fri, 22 Dec 2023 06:24:58 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rGdeE-0000BC-0G for bug-gnu-emacs@gnu.org; Fri, 22 Dec 2023 06:24:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rGdeH-0003b5-W6 for bug-gnu-emacs@gnu.org; Fri, 22 Dec 2023 06:25: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: Fri, 22 Dec 2023 11:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67483 X-GNU-PR-Package: emacs Original-Received: via spool by 67483-submit@debbugs.gnu.org id=B67483.170324429113787 (code B ref 67483); Fri, 22 Dec 2023 11:25:01 +0000 Original-Received: (at 67483) by debbugs.gnu.org; 22 Dec 2023 11:24:51 +0000 Original-Received: from localhost ([127.0.0.1]:46118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rGde6-0003aJ-Lc for submit@debbugs.gnu.org; Fri, 22 Dec 2023 06:24:51 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:10105) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rGddu-0003Zm-V0 for 67483@debbugs.gnu.org; Fri, 22 Dec 2023 06:24:49 -0500 Original-Received: (qmail 36047 invoked by uid 3782); 22 Dec 2023 12:24:27 +0100 Original-Received: from acm.muc.de (p4fe15ca9.dip0.t-ipconnect.de [79.225.92.169]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 22 Dec 2023 12:24:27 +0100 Original-Received: (qmail 14643 invoked by uid 1000); 22 Dec 2023 11:24:26 -0000 Content-Disposition: inline In-Reply-To: <522B6349-614D-48AD-963D-76CF59A30497@gmail.com> 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:276658 Archived-At: Hello, Mattias. On Thu, Dec 21, 2023 at 13:22:17 +0100, Mattias Engdegård wrote: > 4 dec. 2023 kl. 19.19 skrev Alan Mackenzie : > > You've undone the bug fix, and the bug is there again. > Oops. An honest mistake, very sorry about that. Ah, these things happen! No great problem. > On the other hand, these blunders often turn out to be beneficial in > the end because they force us to take a better look at the problem. > I ended up maintaining `byte-compile-form-stack` in `cconv-convert` > which isn't free but a lot better than doing it in the optimiser. We > emit a fair amount of warnings in cconv so this should be useful for > other reasons as well. I don't understand this. What's the process of converting to a closure got to do with maintaining the stack of forms for error processing? cconv shouldn't even be involved at all for dynamic binding - it would seem to me that the only reason for calling cconv in this case is now to get the error handling. This doesn't seem good. What am I missing? > The warning was also reverted from delayed to immediate, which makes > sense in this case (since it's essentially a syntax error) and in fact > it wouldn't work otherwise because delayed warnings implicitly use the > byte-compile-form-stack we have when traversing the post-optimisation > tree in codegen. This seems indeed a good thing. I've never understood the delayed warning mechanism. > I'm inclined to do something about this last problem for good measure > (see attached patch). Whoops! There was no patch. > Most of the time the byte-compile-form-stack doesn't matter much > because the warning argument contains a symbol with position, but when > it does, the stack state in codegen when the warning is emitted is > likely to be less useful than when the warning was registered in the > front-end. Haven't made up my mind about this yet. > > We do indeed, but here binding the variable simply doesn't work. Parts > > of the compiler, when they encounter errors, signal an error which gets > > caught by a condition-case somewhere. > Yes, so I noticed. This is rubbish of course; we should do something > about it. We have some options. Meanwhile I made a macro to > encapsulate the ugly push-pop logic in one place. You've put the new macro into macroexp.el. This file is purely about macro handling. The new macro has nothing to do with this, it is part of the compiler. Surely it should be byte-compile-with-extended-form-stack. And is the "--" in the name appropriate, given that the macro is used by several files? I'm not sure about that rule. Also, byte-compile-form-stack gets bound in cconv-closure-convert. Why? It seems unneeded, and in the event of an error being caught by a condition-case will undo all the good work that came from the tedious discipline of using push and pop rather than binding. But cconv-closure-convert doesn't get called recursively. So it would seem the wrong place to be maintaining byte-compile-form-stack. What's needed is a place where that stack grows steadily as the source code is recursed into, to ensure there will be a correct position on it in the event of an warning/error. I don't think this bug is properly fixed, yet. -- Alan Mackenzie (Nuremberg, Germany).