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: Tue, 29 Oct 2024 18:59:11 +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="4120"; 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 Tue Oct 29 20:00:31 2024 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 1t5rSA-0000s0-SH for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Oct 2024 20:00:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t5rRt-0000IT-JK; Tue, 29 Oct 2024 15:00:14 -0400 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 1t5rRj-000093-KT for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 15:00:03 -0400 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 1t5rRj-0001NH-4K for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 15:00:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=From:In-Reply-To:MIME-Version:References:Date:To:Subject; bh=0XbKKqbNT30j8kOeyQ3Pqpu4YJZLvYAYspoOe7m3fzI=; b=Y2eeOkQQDXmRwToI+Nsu+1Sew3HHRHIwHi0f/1OlGrnmFp6KXbJ9MxpRGOiAL55eATXBlzZ5eAHGvwCQU8bIg0185YYp1ITAL3sbzmhGpIXrFEjkYebYf7EY5C6vx//htFAmYPyo01DfegesZROvPHduaeTcCY0C59G1TLgN2Z0MeLW9PZFRVzBtPlT2AsgHv3uhxOm9K25/iIigaT9NQfr3bau6KrRT1QREIDYXuec2OoIhS1jdYSpm3jGKX6DTCUIJvraDu1kTOaYNbGazaKFdj86IwRHuTm2zfCwN7f3wDraD1Ri2V1jq0fKS7t8m24GvREhCF29IqGCGskGweA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t5rRi-0006iK-UE for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 15:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Oct 2024 19:00: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.173022836225765 (code B ref 66912); Tue, 29 Oct 2024 19:00:02 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 29 Oct 2024 18:59:22 +0000 Original-Received: from localhost ([127.0.0.1]:58150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5rR4-0006hU-5y for submit@debbugs.gnu.org; Tue, 29 Oct 2024 14:59:22 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:15979) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5rR1-0006hN-Ik for 66912@debbugs.gnu.org; Tue, 29 Oct 2024 14:59:20 -0400 Original-Received: (qmail 43641 invoked by uid 3782); 29 Oct 2024 19:59:12 +0100 Original-Received: from muc.de (p4fe1578b.dip0.t-ipconnect.de [79.225.87.139]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 29 Oct 2024 19:59:12 +0100 Original-Received: (qmail 24373 invoked by uid 1000); 29 Oct 2024 18:59:11 -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:294525 Archived-At: Hello, Stefan. It's been almost a year since this bug got lost in the storm of other things which needed doing. I'd like to come back to it now. To refresh your memory, the problem was about not getting any information about foo when an error occurred during (require 'foo). And no apologies for the top posting, which just seems appropriate, since new possibilities (handler-bind in particular, thanks!) have appeared in the last year. My latest idea is to put (the C equivalent of) handler-bind around the readevalloop call near the end of Fload. So with my test files from last year, in place of the current error output test-byte-compile-errors.el:2:11: Error: Wrong type argument: listp, baz the following line would appear: test-byte-compile-errors.el:2:11: While loading "test-byte-compile-errors-2.el" Error: Wrong type argument: listp, baz .. The "While loading "foo.el" " bit would be repeated as needed for nested (require 'foo)s. OK, the error line could be quite long, but the information would at least be there. This could surely be achieved with something like the following in Fload: (handler-bind ((lambda (err) (signal (car err) (combine-error-info "While loading " file (cdr err))))) readevalloop (Qget_file_char, &input, hist_file_name, 0, Qnil, Qnil, Qnil, Qnil);) (where, obviously, the details need to be worked out). It would need augmenting with handling for (eq debug-on-error t), and probably a few other things, too. What do you think of the idea? -- Alan Mackenzie (Nuremberg, Germany). On Sun, Nov 12, 2023 at 16:19:36 -0500, Stefan Monnier wrote: > >> 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? > I think we print a "bare" error message (together with the location of > the macro call). Often it's good enough (e.g. when the error is really > in the macro call itself). Sometimes it's very perplexing :-( > > It the answer is no or not really, we should give her the backtrace to > > get started on. > Says the one who claimed earlier that backtraces are stressful :-) > Dumping the backtrace is a kind of cop-out. > Don't get me wrong, I love backtraces, but I don't think we should > blissfully throw backtraces at unsuspecting users (unlike Python, say). > IOW, we should first work harder to provide better error messages. > >> 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. > Agreed. > >> 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. > We don't even give that info. We just give the line number of the > `require`. It's almost as good as the outermost file name, but not quite. > > 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. > Hmm... I can't think of such a situation. When/where do we show > a backtrace without the user's explicit request? > >> 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. > AFAICT this would basically be equivalent to aliasing > `byte-compile-debug` to `debug-on-error`. > It may turn out to be annoying occasionally, but I think it's worth > a try (I've never found it useful to have `byte-compile-debug` set to > t without also setting `debug-on-error` to t). > Stefan