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#66912: With `require', the byte compiler reports the wrong file for errors. Date: Sun, 12 Nov 2023 16:30:06 +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="11176"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 66912@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 12 17:31:51 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 1r2DNH-0002hl-4I for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 Nov 2023 17:31:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2DMq-0007wl-3s; Sun, 12 Nov 2023 11:31:24 -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 1r2DMo-0007wc-E3 for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 11:31:22 -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 1r2DMn-0005HH-LJ for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 11:31:22 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r2DNS-0002ZQ-2E for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 11:32: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: Sun, 12 Nov 2023 16:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66912 X-GNU-PR-Package: emacs Original-Received: via spool by 66912-submit@debbugs.gnu.org id=B66912.16998066669801 (code B ref 66912); Sun, 12 Nov 2023 16:32:02 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 12 Nov 2023 16:31:06 +0000 Original-Received: from localhost ([127.0.0.1]:56823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2DMW-0002Xz-4W for submit@debbugs.gnu.org; Sun, 12 Nov 2023 11:31:06 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:10480) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2DMQ-0002XQ-4O for 66912@debbugs.gnu.org; Sun, 12 Nov 2023 11:31:02 -0500 Original-Received: (qmail 92501 invoked by uid 3782); 12 Nov 2023 17:30:10 +0100 Original-Received: from acm.muc.de (pd953a91f.dip0.t-ipconnect.de [217.83.169.31]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 12 Nov 2023 17:30:09 +0100 Original-Received: (qmail 22746 invoked by uid 1000); 12 Nov 2023 16:30:06 -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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:274209 Archived-At: Hello, Stefan. On Fri, Nov 03, 2023 at 12:09:03 -0400, Stefan Monnier wrote: > > The pertinent error information is discarded by one of two > > condition-cases in the macro displaying-byte-compile-warnings in > > emacs-lisp/bytecomp.el. > Kind of, yes. But the info available there is hard to use: basically at > that point we could get the error message and the backtrace, which is > what we get when we set `byte-compile-debug`. In the case where > `byte-compile-debug` is not set, we don't really want to display > a backtrace, .... Why not? We're not in the compilation any more, we're loading a file. Some error has prevented that file loading, so we want a backtrace just as we would get with M-x load-file foo.elc RET. > .... so we'd have to "analyze" that backtrace to try and extract a > useful error message from it, which is hard&brittle. Indeed, so. > > If these condition-case's are disabled (for example by spiking the > > enclosing `if' forms) > By "spiking" do you mean setting `byte-compile-debug`? I actually commented out byte-compile-debug, replacing it with t. But same idea, yes. > > This appears to be a fundamental problem with condition-case. When an > > error occurs, the stack gets unwound before the error handlers have a > > chance to analyse it. > [ This is going a bit on a tangent, but I think it would be good to add > some support for something like Common-Lisp's `handler-bind`, > i.e. error handlers that are run before unwinding the stack (so they > can capture the stack trace as well as the value of dynbound vars at > the moment the error occurs, for example). > It would make it possible for ERT to refrain from activating > `debug-on-error`, for example (which it does in order to capture the > backtrace at the time of the error). ] That sounds kind of useful. > I think for this specific problem being discussed (which is indeed > a fairly common occurrence in my experience), the better solution is to > change `load` so it adds the "context" (i.e. filename and ideally also > the approximate file position info) to errors. > [ This may require something like `handler-bind`. ] Another solution would be to dispense with display-byte-compile-warnings, just letting compiler errors generate backtraces. The problem here is that there is no distinction in bytecomp.el between "external" errors (such as from require) and errors detected by the compiler in the source file being compiled. The first decidedly want a backtrace, the second probably not. All these errors are handled as though they were "internal" errors detected by the compiler. This is suboptimal. Perhaps we should report the second type of error (detected by the compiler) by calling a warning function, as we do for warnings, and removing the damaging condition-case's as suggested two paragraphs back. > Stefan -- Alan Mackenzie (Nuremberg, Germany).