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: Wed, 6 Nov 2024 20:12:43 +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="33998"; 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 Wed Nov 06 21:13:22 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 1t8mP4-0008bo-4b for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Nov 2024 21:13:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t8mOn-0003Sl-1E; Wed, 06 Nov 2024 15:13:05 -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 1t8mOl-0003SY-AH for bug-gnu-emacs@gnu.org; Wed, 06 Nov 2024 15:13:03 -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 1t8mOl-0008WQ-1i for bug-gnu-emacs@gnu.org; Wed, 06 Nov 2024 15:13:03 -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=LzmskrzRcx48l73LeWj3x1Tb65ZzQQ+WkPT/5Cevr5k=; b=B2dfUQNwGqPOXmEAQlD0GyjPhgbqz8pucNoD6eTq0fjtw6bsKH7SlRjnyo+B5gbaYgkjVRn+3uKPmS2h6D/YUk2VJrAm2lU+2oRHC8Tl4LorerB1jkMOCR2jF9xgnb/ZOzX066zoNlEFnEv5o5bZuUNraiueOJfDL2Vk02nsXgfY83oMIfxfStpyv7U6cs1Gh0CN/4TAA+Jhle2RU0JJueupioXqM2/xx+Sg+FXdN+a+7oUqGWnL4NYkYSqtqvM8y2CFBnlIP8ghAk/09kbCRfKetgVrvgXr7MSSUHP0kLesVCdiRPwB0r2tKWVer4L7NRY80j38nkOg/Fu6q2jH3w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t8mOk-0001vv-9a for bug-gnu-emacs@gnu.org; Wed, 06 Nov 2024 15:13: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: Wed, 06 Nov 2024 20:13: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.17309239737413 (code B ref 66912); Wed, 06 Nov 2024 20:13:02 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 6 Nov 2024 20:12:53 +0000 Original-Received: from localhost ([127.0.0.1]:45590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8mOb-0001vV-66 for submit@debbugs.gnu.org; Wed, 06 Nov 2024 15:12:53 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:19320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8mOY-0001vF-FL for 66912@debbugs.gnu.org; Wed, 06 Nov 2024 15:12:51 -0500 Original-Received: (qmail 44047 invoked by uid 3782); 6 Nov 2024 21:12:44 +0100 Original-Received: from muc.de (p4fe15b0f.dip0.t-ipconnect.de [79.225.91.15]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 06 Nov 2024 21:12:44 +0100 Original-Received: (qmail 5611 invoked by uid 1000); 6 Nov 2024 20:12:43 -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:294978 Archived-At: Hello, Stefan. On Wed, Nov 06, 2024 at 13:51:05 -0500, Stefan Monnier wrote: > >> I was thinking we wouldn't bother, just like the we don't bother > >> emptying the match-data after we used it. > > I'm getting problems when debug-on-error is non-nil, and a *Backtrace* > > is on the screen. At this stage, Vloads_in_progress is still non-nil. > Right, because we're still in the process of loading those files. > > So when another error occurs, even a trivial one like "next-line: End of > > buffer", its error message gets prefixed by the "While loading ..." > > strings. > Of course. Of course? You foresaw this and didn't tell me about it. :-) > This is an instance of the problem I described as follows: > But I don't think it would be correct in all cases: if file A loads > file B which compiles file C which loads file D which signals an > error we want the compiler error message to say "error in D loaded > from C" and not "error in D loaded from C loaded from B loaded from A". No, I don't think so. Loading a file which compiles another file is somewhat unusual, to say the least. I don't recall seeing it anywhere in Emacs. What the message would say in such a circumstance is "While loading A... While loading B... While loading D... \n(Wrong type argument listp baz)". This is accurate, though maybe not the whole story in the case where there's a compilation in the middle of all that lot. This case is probably rare enough not to matter. > > This is a Bad Thing. Do you have any suggestions for a fix? > Other than changing to another approach (e.g. one that incrementally > adds the context info via `handler-bind`s so you only get the context > that found "between" the error and the place where we actually handle > the error), .... I don't really understand that at the moment. I'll need to think about it. > .... I think the easy solution is to consider not the whole > `Vloads_in_progress_of_last_error` but only the part which is not > still present in `Vloads_in_progress`. In either case, the simplicity of the approach, which was meant to recommend it, has disappeared, being replaced by appreciable complexity. > Something like > (while (not (equal Vloads_in_progress_of_last_error Vloads_in_progress)) > (setq msg (concat msg " while loading " > (pop Vloads_in_progress_of_last_error)))) This doesn't make sense in the current implementation (sorry for not sending you a patch), because Vloads_in_progress_at_error is copied from Vloads_in_progress in signal_or_quit. > > I've tried it, and the above problem seems definitely to make it less > > simple than the approach I originally took (which currently works). > AFAIK, your previous approach suffered from the exact same problem, tho > maybe in fewer cases. No, it doesn't. There, Vloads_still_in_progress is kept in synch with Vloads_in_progress when Fload operations start and end. When the debugger or error handler outputs a message using Vl_still_i_p, it resets that variable to nil, preventing it getting output again. That strategem isn't available in the newer approach, where Vl_i_p_at_error gets "refreshed" at each error occurring in the debugger's recursive edit. At the moment, I think my currently working solution is the best way to go. > Stefan -- Alan Mackenzie (Nuremberg, Germany).