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: Tue, 05 Nov 2024 14:00:43 -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="33192"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 66912@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 05 20:01:25 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 1t8Onr-0008Qi-MS for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 Nov 2024 20:01:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t8Ona-0000zW-4J; Tue, 05 Nov 2024 14:01:06 -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 1t8OnX-0000zL-Sv for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 14:01:04 -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 1t8OnW-0001oj-Te for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 14:01:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=TpoXT1H/BkMHJHhLAfA4cE0zWYinJS+M8PUUhn4prLg=; b=dGD0zzJIkNnP8DqRvmgcCoCABMrb+A8VqlLyW+se3+yqewx8Hp2Trmc91lSggeK9oc1MkisFTP1tDcaPjYmbJVeF0tMUzfbb3HIdLJBeVF+vuk1Uyzx0ied64M6FER6eVnsc2Kb+BS1ckxBtiRoMfSfJRuBNFOdequxRCRkp3BnL6bgcs/rtxRdhPyU80W470sAeO3cN7kGWdhroIn6b1F/z0JzRIuIKlaVQZgHylHcpbT4o4uqUWTOxfCE7tZYHS6IBlF0+OndQDoF2r6lP5v9Gdl0fy9HZO36u5pXSHEA+V7tWYA4k4RpziXANlPrammjuGKtuD7vz6Kc2nWen3Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t8OnW-0001J0-IZ for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 14:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Nov 2024 19:01: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.17308332615004 (code B ref 66912); Tue, 05 Nov 2024 19:01:02 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 19:01:01 +0000 Original-Received: from localhost ([127.0.0.1]:37908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8OnU-0001Ie-Un for submit@debbugs.gnu.org; Tue, 05 Nov 2024 14:01:01 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8OnS-0001IK-E2 for 66912@debbugs.gnu.org; Tue, 05 Nov 2024 14:00:59 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6940B444AB7; Tue, 5 Nov 2024 14:00:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730833251; bh=LqUDOqHVb+5g+nkjCta7UCyXkmp6a1A+l6LJ/fYhWSI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pKvyOwhDlS6bCf1Q9jA+1GGAi2imUZFa6Y+mBybVRmGmeof896CoYLbDu7Wa2mGPM rtu45JCFNxDK5qjuejRgb6BOptvtoyUrAQ1cJ1Kl9LmCNknA8JcT/o3aBlXt/rbkIo UvBRyi5K44Zo6YYyyV0VSQVc6WAWWmAYP9gtMlo1tvmgYbasPVCXh7SBq0jhiG1h4/ 8U1S53Tzj59Bgz2iYVGv6DR86FagqoTkZ9Wm5hW79UwiXI26htdIlP0Lf723d/UCHJ 4HSLbaTO4QnCVROxaiHMgzUra8GXTFt79PE/DB66w0fRLQYHayswNFjDl3SiQybNJg iyb5cLZpMuzBQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1DC02444AAC; Tue, 5 Nov 2024 14:00:51 -0500 (EST) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0CDF212033B; Tue, 5 Nov 2024 14:00:51 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Tue, 5 Nov 2024 14:54:24 +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:294917 Archived-At: >> > Here's the amended patch. It's a lot shorter (and easier) than the >> > previous version. I would like to commit it as the fix to bug#66912. > >> Thanks. I'm not in love with this approach, among other things because >> of the problem I described earlier: > >> 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". > >> but it's not the end of the world, so I don't object to installing it on >> `master`. > > OK, thanks! > >> > 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 `Vload_in_progress` into the global variable `Vload_in_progress_of_last_error`. So the doc doesn't need to explain how `Vload_in_progress_of_last_error` "survives unbinding", it can just say it's the info that was current when the last error was signaled. 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. 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. > 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. Stefan