From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors. Date: Sun, 12 Nov 2023 16:19:36 -0500 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19532"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 66912@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 12 22:20:45 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 1r2Hsr-0004sD-6i for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 Nov 2023 22:20:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2HsW-0004JM-RS; Sun, 12 Nov 2023 16:20:25 -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 1r2HsT-0004IW-Ok for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 16:20:21 -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 1r2HsT-0005GT-7r for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 16:20:21 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r2Ht7-0001yi-VS for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 16:21:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Nov 2023 21:21: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.16998240347554 (code B ref 66912); Sun, 12 Nov 2023 21:21:01 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 12 Nov 2023 21:20:34 +0000 Original-Received: from localhost ([127.0.0.1]:57151 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2Hsc-0001xi-LC for submit@debbugs.gnu.org; Sun, 12 Nov 2023 16:20:33 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2HsY-0001xS-F6 for 66912@debbugs.gnu.org; Sun, 12 Nov 2023 16:20:29 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BE358801D4; Sun, 12 Nov 2023 16:19:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1699823977; bh=/loNEui/viZvwhh6UI9dWfynRmX8bL6Sc3r1N4bR1qc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=dZFlRL8DEhrwGtG8DA1LGbXOfd5THX9qPP9sAIIEAFk1onPlqYzkVEKsHKfAms+LO Wr5iXodE3z1Xh4JnRW4YtvtZgStSoZqKIabWNnu7sdlM5xoKj0YEVmDx+OqXOfGKUI KscHRmyH0StVmgwI3a70vymKAPS4/yqGHUK0lxjKiMiWvs2raVmdev6KZYl05aTcqJ 55iSgtDxb9O+UaX5I4Zej3sfuBAqU+TwHaFLhDZwSyWXL/7YvPsTnQ6ppWxkTEPgB2 8y9PbzAdEG9uM0XuD157X1P5iHPJgPEaUiTpJnX9brSSIAmLVYW0y6Z3UHVvNp0xJe DgwWicBfYXR0A== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C68CB80578; Sun, 12 Nov 2023 16:19:37 -0500 (EST) Original-Received: from pastel (unknown [45.72.227.120]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9D0F3120209; Sun, 12 Nov 2023 16:19:37 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Sun, 12 Nov 2023 20:41:39 +0000") 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:274235 Archived-At: >> 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