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: Thu, 7 Nov 2024 17:15:49 +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="25709"; 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 Thu Nov 07 18:16:31 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 1t967T-0006Xn-Fs for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Nov 2024 18:16:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t9674-0004Kq-Qe; Thu, 07 Nov 2024 12:16: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 1t9670-0004KH-K9 for bug-gnu-emacs@gnu.org; Thu, 07 Nov 2024 12:16: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 1t9670-0003Ij-BO for bug-gnu-emacs@gnu.org; Thu, 07 Nov 2024 12:16: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=si64qlm7tERffT7xjb0mLWKTgBCMu3mTpEiVoZIjdZU=; b=QDV8gRt7l1ZFGXezT0MBlyeG4l8YWpTXDxfU9DG/KmmocqBdlr9+0xPqFRFoBvopB1Fl9zYRCx5wUrXkuYX00hlJwakdAGWzzGDUdTdndZntWiWfabh4bl//G95T05j7oLQWfhlsOf3RKzpQRaNubn78pYOCdz0qzFWjGT5nV+w464jc/y8YL1tvPuH53Jq3NgwqH6PAYMV5iowHDzb5IhVAhBi6o/iR1FLZPsSxZi5hkiBHalEvlClUwqMNf4Qy3ADfFdJ57+IZqh8xlQb3iiviFScMGKRoffTXaklS0nqBATTLrvF4pc+i90nLurQWXnrHhwjEF8OkM8HvBj1hmw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t9670-0001Yt-5U for bug-gnu-emacs@gnu.org; Thu, 07 Nov 2024 12:16: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: Thu, 07 Nov 2024 17:16: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.17309997605995 (code B ref 66912); Thu, 07 Nov 2024 17:16:02 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 7 Nov 2024 17:16:00 +0000 Original-Received: from localhost ([127.0.0.1]:49444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t966x-0001Yd-Qt for submit@debbugs.gnu.org; Thu, 07 Nov 2024 12:16:00 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:24683) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t966v-0001YK-5p for 66912@debbugs.gnu.org; Thu, 07 Nov 2024 12:15:58 -0500 Original-Received: (qmail 71844 invoked by uid 3782); 7 Nov 2024 18:15:50 +0100 Original-Received: from muc.de (p4fe15e61.dip0.t-ipconnect.de [79.225.94.97]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 07 Nov 2024 18:15:50 +0100 Original-Received: (qmail 20277 invoked by uid 1000); 7 Nov 2024 17:15:49 -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:295035 Archived-At: Hello, Stefan. On Thu, Nov 07, 2024 at 11:09:19 -0500, Stefan Monnier wrote: > > OK, I see what you mean. But if the error gets handled in a handler-bind > > handler, or goes through to the debugger without being intercepted by a > > condition-case, the binding stack will not have been unwound. In that > > case the difference between the two lists would be empty. > Indeed, these are cases where the error hasn't reached its corresponding > handler yet. Do you think it's a problem? 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'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. > >> You may be right that the "fewer" case are so few so that there really > >> aren't any. I'm not convinced there cannot be a code path that happens > >> not to pass via those settings to nil, but maybe you're right. > >> Still, my A => B => compile => C => D examples still stands, which is > >> still at heart the same problem IMO, and could be worked around with my > >> `while` loop above. > > One way to fix this would be to make Vloads_still_in_progress visible to > > Lisp, and to bind it to nil in the byte compiler. But that might get a > > bit complicated. > And if an error in D gets handled in A, you'd have lost part of the "A > => B => compile => C => D" context information because the rebinding to > nil would cause `Vloads_still_in_progress_at_error` to contains only > the "C => D" part. Yes. As I say, it could get complicated. I don't think such a binding in the byte compiler is a good idea, but it's a possibility. > > 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! It is a very simple mechanism, easily understood, and it worked without known error for several years, before being replaced by something more complicated. How do you think this mechanism could go wrong if used again for Vloads_still_in_progress? > Stefan -- Alan Mackenzie (Nuremberg, Germany).