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: Wed, 06 Nov 2024 18:14:18 -0500 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15278"; 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 Thu Nov 07 05:01:32 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 1t8ti8-0003ra-5f for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Nov 2024 05:01:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t8thi-0004l8-KC; Wed, 06 Nov 2024 23: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 1t8thg-0004kq-0z for bug-gnu-emacs@gnu.org; Wed, 06 Nov 2024 23: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 1t8thf-0002nJ-3N for bug-gnu-emacs@gnu.org; Wed, 06 Nov 2024 23: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=9EQ9GArvjJeEKgbtqAz3wJin8QMU8NNoHNxn25p3VAM=; b=OnnV8hKdWhCgDg5070+W0MkBBJAGtmE8IogtMVRP6GTJDCm7aswmg5+QcZIshmIRN3K5fQZtsgK7pzxI3Z9ap7iFTa9qO9iUG/92dobhwt9haE3VK5HWsH6C7+ObpP8711pVFhKDG6qa2jHn/7U+p3+UNKE5E3T5f0RqiDBs+V/nlII1T7B1fMeLKClmOHf1Zh0lJgfkj/RYPWX+Egz3mjvlDOWFUh6cmWiPqDtTgzx7AqDdr7dGnJpK+v4nG8YJhuirwjrypuEoGT72ERycKCBm0+fXm65fKUlt82lNkNkuB/sJQskztL1Hl51/R5abSM4wZYKIT+Bhs5P62UjxnQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t8thd-00088d-L6 for bug-gnu-emacs@gnu.org; Wed, 06 Nov 2024 23:01:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Nov 2024 04:01: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.173095201631029 (code B ref 66912); Thu, 07 Nov 2024 04:01:01 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 7 Nov 2024 04:00:16 +0000 Original-Received: from localhost ([127.0.0.1]:46805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8tgu-00083s-8X for submit@debbugs.gnu.org; Wed, 06 Nov 2024 23:00:16 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8tgr-00080t-Qz for 66912@debbugs.gnu.org; Wed, 06 Nov 2024 23:00:14 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E021A100383; Wed, 6 Nov 2024 18:14:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730934858; bh=0dKTUYNUYfHLS18dSkVU8on9/IzioeEFyiIpmMT6H/o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FIs/Qr/jeyY27dH5FX52d0xwGgputTMANeT3CIQa1egimnI4jSNUPM7j9jq5Ys6AD 5LH4Tf4K87Qpey+zyh1eLAKuqHSXR+BSg7mm4eTLmeK1CKrcYtweiQ2HQ7GEM33BBY SJqfEPDdz5xbSx6vquK3ngLnOP4s2qV2vNgrMNrQIasKoro9kr3jezeqBfTDrN1n+q nEqQBoAIsI6qvmD3QsNugwWlTE98IXYW8QLNbREMomKYm6c4Q9QzBCGrvlbobOBEnW awW9q5L4gZbLRoIPXOwBefn1P2HkHnxhwY2sJPRiP4iMV4SqVwZfhp4QPH3B1Nrdoe D2Vt47lHHipJQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A3B911001DE; Wed, 6 Nov 2024 18:14:18 -0500 (EST) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8E2D81203DA; Wed, 6 Nov 2024 18:14:18 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Wed, 6 Nov 2024 20:12:43 +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:294990 Archived-At: >> (while (not (equal Vloads_in_progress_of_last_error Vloads_in_progre= ss)) >> (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 don't understand why you say it doesn't make sense: An error in signaled from with a =3D> B, so in `signal_or_quit` you copy `Vloads_in_progress` which contains `("B" "A")` to `Vloads_in_progress_at_error` and then you throw the error at the condition-case which was installed (say) from within the file A so when you reach the handler, `Vloads_in_progress` will have been reset to `("A")` so the above loop will correctly say that the error occurred from within B. >> > 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 =3D> B =3D> compile =3D> C =3D> D examples still stands, which = is still at heart the same problem IMO, and could be worked around with my `while` loop above. > At the moment, I think my currently working solution is the best way > to go. [ As you can guess, I disagree, mostly because I think the problems of my suggested approach are "familiar", since the behavior can be compared to things like the match-data, so we know how to live with its shortcomings, whereas I can't think of something else we already have which follows an approach like yours, so we're in new territory and it's harder to see what the problems could be and what workarounds to use. ] Then you'd be better get cracking at the documentation of "survives unbinding" =F0=9F=99=82 Stefan