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: Fri, 8 Nov 2024 20:01:54 +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="31944"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, Eli Zaretskii , 66912@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 08 21:03:16 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 1t9VCN-000843-FE for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 08 Nov 2024 21:03:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t9VCB-0006yT-U7; Fri, 08 Nov 2024 15:03:04 -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 1t9VCA-0006yH-OH for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2024 15:03:02 -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 1t9VCA-0007aB-FY for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2024 15:03:02 -0500 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=qDGAWxr6rHoQf76oBFbRl1qI36OzgUa8HP1ZNp+Dw/Q=; b=ZkYygTlhZSVw/QM+1nZAAqq+qBgEC16/mURexwr3qlHdIsY8cnsIye9Bsd7i6y06TmyjOPlD0iqJgwXHB2AdK54cmVNXZB/RnDhJ3Zc7NrcjPwuWEWgbIQaROMJZ5eABRRENB3U50GrD9W0RMP4yJtBkx3uCWa2CZZM5AUdUDWTtd7AyQ74HkVFdOGftjDDh4ErB+WsxDXlKIj7gUhCWsWdXzDSsyOnFJmZt/ig1sAnpLd8gAHOTA9NpaRb6QjNvXR4cwlIXw82L0FNJYEuKVbHYaYU01WDfMVB1KrYXMoXZGJeIFFJjZdkMVlYS3lvJfYVfkd+gnqZF+A8jsR8R+A==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t9VCA-0007m6-9w for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2024 15:03: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, 08 Nov 2024 20:03: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.173109612629816 (code B ref 66912); Fri, 08 Nov 2024 20:03:02 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 8 Nov 2024 20:02:06 +0000 Original-Received: from localhost ([127.0.0.1]:52238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9VBF-0007kq-KB for submit@debbugs.gnu.org; Fri, 08 Nov 2024 15:02:05 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:45772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9VBC-0007k2-5G for 66912@debbugs.gnu.org; Fri, 08 Nov 2024 15:02:04 -0500 Original-Received: (qmail 6579 invoked by uid 3782); 8 Nov 2024 21:01:55 +0100 Original-Received: from muc.de (p4fe150f0.dip0.t-ipconnect.de [79.225.80.240]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 08 Nov 2024 21:01:55 +0100 Original-Received: (qmail 12355 invoked by uid 1000); 8 Nov 2024 20:01:54 -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:295086 Archived-At: Hello, Stefan. On Fri, Nov 08, 2024 at 08:42:29 -0500, Stefan Monnier wrote: > > Yes. When the debugger handles the error, the binding stack hasn't been > > unwound at all, so Vloads_in_progress and Vloads_in_progress_at_error are > > EQ. So the difference between them would be empty. > I understand that, but I don't think it explains why you think it's > a problem. E.g. when you're in the debugger, you can see the stack > trace which tells you we're loading A, so you don't need to be told > "while loading A" in the error message. OK, I see what you mean. I took it for granted that the message should be the same, regardless of whether it is reported by a debugger or by the error handler. You're suggesting that's not really necessary. There may be some way the message might be output by a handler-bind handler before the stack gets unwound, but which doesn't end up with a debugger backtrace. I haven't really thought that through yet. Even when the information is in a debugger backtrace, I think there would be merit in outputting "While loading foo.el... " as part of the error message. In the backtrace, the succession of entries for Fload is going to be dispersed and not all that easy to trace, but is likely to be one of the first things the person debugging will want to see. > >> > Something very similar, if not the same, was the original handling of > >> > byte-compile-form-stack. > >> Something only you worked with, AFAICT. So it doesn't have the same > >> "known issues" advantage for the rest of us. > > Oh, come on, Stefan! > I'm just describing the way I see it: I personally don't have a good > intuition of how/when it could misbehave nor how to work around such > cases, whereas I very much do for the approach I propose and AFAICT it's > not just because I proposed it but it's because it follows > a known pattern, so I expect the same will hold for other coders. Experience with byte-compile-form-stack suggests it won't misbehave. It's simplicity should make it easy to think through. > Of course it wouldn't be the first time I'd be wrong. Also, I didn't > say I objected to your approach, I just have a different preference: you > don't have to convince me. In the approach where we copy Vloads_in_progress inside signal_or_quit, we still don't have a reliable way of preventing the "While loading foo.el... " from getting into other messages where it doesn't belong, like "end of screen". You've suggested taking the difference between Vloads_in_progress at two stages of the error handling. I'll admit I haven't tried that out yet, but it feels to me complicated and fragile. It feels we've lost momentum for this fix. I still favour my current version of the patch, which works, and I think is simpler than the alternative approach. It would be nice to get this finalised and committed. > Stefan -- Alan Mackenzie (Nuremberg, Germany).