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, 5 Nov 2024 20:33:23 +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="11126"; 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 Tue Nov 05 21:34:33 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 1t8QG0-0002kD-57 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 Nov 2024 21:34:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t8QFe-0007TK-MC; Tue, 05 Nov 2024 15:34:10 -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 1t8QFX-0007SP-G7 for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 15:34:05 -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 1t8QFW-0002Vm-P8 for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 15:34: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=ONp1AdMBsCbaPUyxpI1PwK/hiSyk2Nfer2AVH/4vG/g=; b=rhremuqXt3wnkq9qo/Fu3Kvn9zAY3xDOErOaba0ilBKUBrTYFqjXu+/SXyu3R+kw1x4okoA6ihrx0606BKENW0Uisu0zcWwGo547XC5iTctCndk5BhuP3tVqrOF/mMgb+Swq9UKROLrxEBRR8Gpj1cXVTHerV/iWCLv2FPAXHPKEBmPDI+4g7Ydy9S4lZEuczohveNnfPX0ebOIh2gjPLfoR6jYQciwjXFDjnmJRLeRc0diwHy86pXh7NjWI76e+6DjIjurS8gwpRNWmw9ocabfhaM+d6TnAuOxZIHoCAKdQ+gWxoqAvGpBGP+qnBLYaqgQ+b+oMZlous1chXg/PZg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t8QFV-0005Oi-MC for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 15:34: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: Tue, 05 Nov 2024 20:34: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.173083881320712 (code B ref 66912); Tue, 05 Nov 2024 20:34:01 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 20:33:33 +0000 Original-Received: from localhost ([127.0.0.1]:38095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8QF3-0005O0-9P for submit@debbugs.gnu.org; Tue, 05 Nov 2024 15:33:33 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:22073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8QF1-0005Nl-CX for 66912@debbugs.gnu.org; Tue, 05 Nov 2024 15:33:32 -0500 Original-Received: (qmail 27249 invoked by uid 3782); 5 Nov 2024 21:33:25 +0100 Original-Received: from muc.de (p4fe159f4.dip0.t-ipconnect.de [79.225.89.244]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 05 Nov 2024 21:33:25 +0100 Original-Received: (qmail 15237 invoked by uid 1000); 5 Nov 2024 20:33:23 -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:294922 Archived-At: Hello, Stefan. Here are some of my thoughts on your new idea. They probably seem a bit incoherent, for which I apologise. I'm trying to think up all the problems we might have with it first, before trying to implement it. That will hopefully reduce frustration and hassle. On Tue, Nov 05, 2024 at 14:00:43 -0500, Stefan Monnier wrote: > >> > static Lisp_Object Vloads_in_progress; > >> > +/* The same as the above, except it survives the unbinding done in the > >> > + event of an error, and can thus be used in error handling. */ > >> > +Lisp_Object Vloads_still_in_progress; > >> Please clarify how "it survives the unbinding". > > It is a global variable which never gets bound, hence when an error is > > signalled and the binding stack unwound, it keeps its value. But you > > want me to write this into the comment, not just explain it here. ;-) > > I've become a little uncertain about this mechanism. Should an error > > occur during loading, and the code somehow avoid calling > > prefix-load-file-names, perhaps by some obscure setting of `debugger', > > Vloads_still_in_progress would stay non-nil, and pollute the next error > > message to be output. I think the default global value of > > Vloads_still_in_progress should be Qnil, and I should bind it to itself > > each iteration of the command loop, probably in command_loop_1. That > > would protect it from wierd uses of recursive_edit, and avoid the need > > to reset Vloads_still_in_progress in prefix-load-file-names. > > What do you (or Eli) think? > BTW, stepping back a little I wonder if we shouldn't do it a bit > differently: > In `signal_or_quit`, stash the current value of `Vloads_in_progress` into > the global variable `Vloads_in_progress_of_last_error`. OK. This new variable would then have a guaranteed accurate copy of Vl_i_p. Should signal_or_quit end up re-invoking itself (as happens, for example, when there's a throw to an un-caught symbol, when signal_or_quit throws Qt to Qtop_level), the value of Vl_i_p won't have changed, so setting it twice won't matter. At least, I can't at the moment see how it would matter. > So the doc doesn't need to explain how > `Vloads_in_progress_of_last_error` "survives unbinding", it can just > say it's the info that was current when the last error was signaled. That would be a good thing, yes. There needs to be some mechanism for resetting this variable to Qnil, should the error handler fail to access it. Possibly by binding it somewhere where it's binding will be undone before the next command. Or maybe not, if an error handler is always preceded by setting Vl_i_p_of_last_error for that same error. Also, we need to be careful about condition-cases in debuggers, where an error, even if handled, might overwrite Vloads_in_progress_of_last_error. debug.el and edebug.el both contain condition-cases. We might not like a necessity to access Vl_i_p_of_last_error before evaluating any condition-cases. That would appear to be inviting trouble. As a wild idea, we could bind some flag to Qt in Fload, and only set Vloads_in_progress_of_last_error if the flag is still set. We would clear the flag at the same time as setting that variable, thus protecting it against the next condition-case or whatever. Possibly we could use Vl_i_p_of_last_error itself, by setting it to t near the start of Fload. However, signal_or_quit is supposed to be a general low-level function, and it doesn't seem ideal to bloat it out with special purpose tests. Another possible problem with this wild idea is that debuggers, or parts of them, might need to be autoloaded. This shouldn't be a problem with edebug.el, where the file would be loaded to be able to instrument a form, but I don't think anything's loading debug.el before it gets used. > It may still hold "the wrong info" if by bad luck some other error > occurred between the error in which you're interested and the moment you > can read `Vload_in_progress_of_last_error`, a bit like when > another regexp-match occurs before you use "your match"'s `match-data`, > but at least semantically, I think it is simpler to explain and > understand than your current code. I think that could only happen if there were a bug in a debugger. I think your idea might be better than my current patch, but I doubt it's going to be much simpler. > We could arguably try and generalize this to hold more data than just > the loads in progress, e.g. merging it with the current > `Vsignaling_function`, so call it `dynamic-context-of-last-error` > or something. Let's get it working first. ;-) > > I think I would agree, but this would be difficult for .el[cn] files. > > How about giving the line number just for .el files, something like: > That's what I meant, yes. OK, I'll think about that, but after we've got the basics (see above) sorted out for this bug. > Stefan -- Alan Mackenzie (Nuremberg, Germany).