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 20:41:39 +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="35809"; 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 21:42:39 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 1r2HHz-0009DE-9U for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 Nov 2023 21:42:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2HHj-0004bS-55; Sun, 12 Nov 2023 15:42:23 -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 1r2HHg-0004ZS-O5 for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 15:42:20 -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 1r2HHg-0004pQ-G4 for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 15:42:20 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r2HIL-0000ur-Ig for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 15:43:01 -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 20:43:01 +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.16998217573477 (code B ref 66912); Sun, 12 Nov 2023 20:43:01 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 12 Nov 2023 20:42:37 +0000 Original-Received: from localhost ([127.0.0.1]:57103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2HHx-0000u0-ED for submit@debbugs.gnu.org; Sun, 12 Nov 2023 15:42:37 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:38573) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2HHs-0000tj-HX for 66912@debbugs.gnu.org; Sun, 12 Nov 2023 15:42:36 -0500 Original-Received: (qmail 91819 invoked by uid 3782); 12 Nov 2023 21:41:43 +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 21:41:43 +0100 Original-Received: (qmail 25620 invoked by uid 1000); 12 Nov 2023 20:41:39 -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:274228 Archived-At: Hello, Stefan. On Sun, Nov 12, 2023 at 12:28:13 -0500, Stefan Monnier wrote: > > 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. > Hmm... that's a good point. > >> 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. > These are two fairly "clear" cases, admittedly. > But there are also cases in between where it's less clear, mostly with > errors during macro-expansion where the internal/external distinction is > not always that clear since some macros come from outside but others > come from the very file we're compiling, and where we can't easily tell > if an error is due to a bug in the macro definition or a bug in the use > of the macro. Question: will the user be able to identify the macro and its source file if we just print the bare error message as enforced by displaying-byte-compile-warnings? It the answer is no or not really, we should give her the backtrace to get started on. > > 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. > Also there are 2 questions: > - whether to give a backtrace (and/or enter the debugger). > - when we don't show a backtrace, what info do we put in the error message. > For the first, the current "solution" is to set `byte-compile-debug`. > It's not ideal, and we should improve it, but at least we do have > a solution for it. I suspect byte-compile-debug isn't widely known. Its name is also a bit discordant - it's not necessarily about debugging byte-compile, it's just to get sensible error messages when something goes wrong, especially when that something is not part of the byte compiler. > For the second we currently don't show a good enough info and in my > previous response I focused on that part. Indeed, for the error message which provoked this bug report, the current information is poor indeed. Considering that require's can be nested, we only tell the user the identity of the outermost one. > > 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. > If the user is not asking to see backtraces, the current treatment seems > cleaner than without any `condition-case`. It's "neat and tidy", but at the cost of discarding all useful information. There are other common situations in Emacs where the debugger is entered, or a backtrace output without debug-on-error having to be set. Perhaps this one should join them. > So maybe those `condition-case` should be turned into > `condition-case-unless-debug`? I think this would be a very useful first step. I think it likely a user will set debug-on-error on encountering any unhelpful error message. > Stefan -- Alan Mackenzie (Nuremberg, Germany).