GNU logs - #66912, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 03 Nov 2023 11:34:02 +0000
Resent-Message-ID: <handler.66912.B.169901122629402 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 66912 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier@HIDDEN>
Date: Fri, 3 Nov 2023 11:32:41 +0000
Message-ID: <ZUTaWfQQuGET2Fb2@ACM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
From: Alan Mackenzie <acm@HIDDEN>
Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@HIDDEN;
 helo=mail.muc.de
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)

Hello, Emacs.

When byte compiling file1, and file1 requires file2, should there be an
error in file2, it is reported as being in file1, at the requires line.
This is entirely unhelpful; the reported position should be that of the
error in file2.  Things get even more unhelpful if there is a nesting of
required files, and the error occurs in a deeply nested file.

For an example, create the files ~/test-byte-compile-errors.el:

#########################################################################
;; -*- lexical-binding:t -*-
(require 'test-byte-compile-errors-2 "~/test-byte-compile-errors-2") 
#########################################################################

, and ~/test-byte-compile-errors-2.el:

#########################################################################
;; -*- lexical-binding:t -*-
(defvar foo nil)
(defun bar ()
  (setq foo)) ; <==================
(provide 'test-byte-compile-errors-2)
#########################################################################

..  From an Emacs session, do

    M-x byte-compile-file RET ~/test-byte-compile-errors.el RET

..  This will report the error as

Compiling file /home/acm/test-byte-compile-errors.el at Fri Nov  3 10:14:40 2023
test-byte-compile-errors.el:2:2: Error: Wrong number of arguments: setq, 1

..  This is not the error location.

#########################################################################

Preliminary analysis:

The pertinent error information is discarded by one of two
condition-cases in the macro displaying-byte-compile-warnings in
emacs-lisp/bytecomp.el.

If these condition-case's are disabled (for example by spiking the
enclosing `if' forms) and the necessary defuns recompiled, there instead
appears an error message in the display area.  On setting debug-on-error
to t and repeating the compilation, one gets a backtrace, which whilst
not ideal, is considerably more helpful than the original error message.

This appears to be a fundamental problem with condition-case.  When an
error occurs, the stack gets unwound before the error handlers have a
chance to analyse it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Alan Mackenzie <acm@HIDDEN>
Subject: bug#66912: Acknowledgement (With `require', the byte compiler
 reports the wrong file for errors.)
Message-ID: <handler.66912.B.169901122629402.ack <at> debbugs.gnu.org>
References: <ZUTaWfQQuGET2Fb2@ACM>
X-Gnu-PR-Message: ack 66912
X-Gnu-PR-Package: emacs
Reply-To: 66912 <at> debbugs.gnu.org
Date: Fri, 03 Nov 2023 11:34:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 66912 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
66912: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66912
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 03 Nov 2023 16:11:02 +0000
Resent-Message-ID: <handler.66912.B.169902781128052 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Alan Mackenzie <acm@HIDDEN>
Cc: 66912 <at> debbugs.gnu.org
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZUTaWfQQuGET2Fb2@ACM> (Alan Mackenzie's message of "Fri, 3 Nov
 2023 11:32:41 +0000")
Message-ID: <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
References: <ZUTaWfQQuGET2Fb2@ACM>
Date: Fri, 03 Nov 2023 12:09:03 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=132.204.25.50;
 envelope-from=monnier@HIDDEN; helo=mailscanner.iro.umontreal.ca
X-Spam_score_int: -42
X-Spam_score: -4.3
X-Spam_bar: ----
X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> The pertinent error information is discarded by one of two
> condition-cases in the macro displaying-byte-compile-warnings in
> emacs-lisp/bytecomp.el.

Kind of, yes.  But the info available there is hard to use: basically at
that point we could get the error message and the backtrace, which is
what we get when we set `byte-compile-debug`.  In the case where
`byte-compile-debug` is not set, we don't really want to display
a backtrace, so we'd have to "analyze" that backtrace to try and extract
a useful error message from it, which is hard&brittle.

> If these condition-case's are disabled (for example by spiking the
> enclosing `if' forms)

By "spiking" do you mean setting `byte-compile-debug`?

> This appears to be a fundamental problem with condition-case.  When an
> error occurs, the stack gets unwound before the error handlers have a
> chance to analyse it.

[ This is going a bit on a tangent, but I think it would be good to add
  some support for something like Common-Lisp's `handler-bind`,
  i.e. error handlers that are run before unwinding the stack (so they
  can capture the stack trace as well as the value of dynbound vars at
  the moment the error occurs, for example).

  It would make it possible for ERT to refrain from activating
  `debug-on-error`, for example (which it does in order to capture the
  backtrace at the time of the error).  ]

I think for this specific problem being discussed (which is indeed
a fairly common occurrence in my experience), the better solution is to
change `load` so it adds the "context" (i.e. filename and ideally also
the approximate file position info) to errors.
[ This may require something like `handler-bind`.  ]

        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 12 Nov 2023 16:32:02 +0000
Resent-Message-ID: <handler.66912.B66912.16998066669801 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
Date: Sun, 12 Nov 2023 16:30:06 +0000
Message-ID: <ZVD9jhW_i23vbPTe@ACM>
References: <ZUTaWfQQuGET2Fb2@ACM>
 <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
From: Alan Mackenzie <acm@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hello, Stefan.

On Fri, Nov 03, 2023 at 12:09:03 -0400, Stefan Monnier wrote:
> > The pertinent error information is discarded by one of two
> > condition-cases in the macro displaying-byte-compile-warnings in
> > emacs-lisp/bytecomp.el.

> Kind of, yes.  But the info available there is hard to use: basically at
> that point we could get the error message and the backtrace, which is
> what we get when we set `byte-compile-debug`.  In the case where
> `byte-compile-debug` is not set, we don't really want to display
> a backtrace, ....

Why not?  We're not in the compilation any more, we're loading a file.
Some error has prevented that file loading, so we want a backtrace just
as we would get with M-x load-file foo.elc RET.

> .... so we'd have to "analyze" that backtrace to try and extract a
> useful error message from it, which is hard&brittle.

Indeed, so.

> > If these condition-case's are disabled (for example by spiking the
> > enclosing `if' forms)

> By "spiking" do you mean setting `byte-compile-debug`?

I actually commented out byte-compile-debug, replacing it with t.  But
same idea, yes.

> > This appears to be a fundamental problem with condition-case.  When an
> > error occurs, the stack gets unwound before the error handlers have a
> > chance to analyse it.

> [ This is going a bit on a tangent, but I think it would be good to add
>   some support for something like Common-Lisp's `handler-bind`,
>   i.e. error handlers that are run before unwinding the stack (so they
>   can capture the stack trace as well as the value of dynbound vars at
>   the moment the error occurs, for example).

>   It would make it possible for ERT to refrain from activating
>   `debug-on-error`, for example (which it does in order to capture the
>   backtrace at the time of the error).  ]

That sounds kind of useful.

> I think for this specific problem being discussed (which is indeed
> a fairly common occurrence in my experience), the better solution is to
> change `load` so it adds the "context" (i.e. filename and ideally also
> the approximate file position info) to errors.
> [ This may require something like `handler-bind`.  ]

Another solution would be to dispense with
display-byte-compile-warnings, just letting compiler errors generate
backtraces.

The problem here is that there is no distinction in bytecomp.el between
"external" errors (such as from require) and errors detected by the
compiler in the source file being compiled.  The first decidedly want a
backtrace, the second probably not.  All these errors are handled as
though they were "internal" errors detected by the compiler.  This is
suboptimal.

Perhaps we should report the second type of error (detected by the
compiler) by calling a warning function, as we do for warnings, and
removing the damaging condition-case's as suggested two paragraphs back.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 12 Nov 2023 17:30:02 +0000
Resent-Message-ID: <handler.66912.B66912.169981014615812 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.169981014615812
          (code B ref 66912); Sun, 12 Nov 2023 17:30:02 +0000
Received: (at 66912) by debbugs.gnu.org; 12 Nov 2023 17:29:06 +0000
Received: from localhost ([127.0.0.1]:56935 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r2EGf-00046y-GL
	for submit <at> debbugs.gnu.org; Sun, 12 Nov 2023 12:29:05 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55654)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1r2EGc-00046T-M1
 for 66912 <at> debbugs.gnu.org; Sun, 12 Nov 2023 12:29:03 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 71B7A440F8F;
 Sun, 12 Nov 2023 12:28:15 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1699810094;
 bh=oMxo46cC9EC8dVmEb9V+3QevSy1tIzmJu98udgvDfsc=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=RPmTIrvM6wG79IANkgKHAWpDHSRFvjrVtghQ/VAcJBvGFyOrtZbMBABoy3BfzG22K
 x61wk3PWYKSvEzwE0X40XBR5rSXI/UbaYimzy2qY8xu+bNOK7F2Az1P+Hk/E0kRHhU
 oZ2JuDcKNroILL5B2FohlEpcPTgDiDW1Bwm664hWKU8TRdVppZgUtsFFOBxMUYHdIW
 c01iK78M8umg23+NLYfwgui03jV4AQSxpSRd8PZ+2MDi645fstJiirJ7Fe0mMBp+M5
 cDqoohqHCrExIPKdXQ2tnzaULCuXD3GTIQFtT94BcgA9PPI1+/p4g728aWPxepyW0B
 4D2Nfz6fRLGSw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 156A3440A25;
 Sun, 12 Nov 2023 12:28:14 -0500 (EST)
Received: from pastel (unknown [45.72.227.120])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E0D96120388;
 Sun, 12 Nov 2023 12:28:13 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZVD9jhW_i23vbPTe@ACM> (Alan Mackenzie's message of "Sun, 12 Nov
 2023 16:30:06 +0000")
Message-ID: <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
References: <ZUTaWfQQuGET2Fb2@ACM> <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
 <ZVD9jhW_i23vbPTe@ACM>
Date: Sun, 12 Nov 2023 12:28:13 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.022 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Why not?  We're not in the compilation any more, we're loading a file.
> Some error has prevented that file loading, so we want a backtrace just
> as we would get with M-x load-file foo.elc RET.

Hmm... that's a good point.

>> I think for this specific problem being discussed (which is indeed
>> a fairly common occurrence in my experience), the better solution is to
>> change `load` so it adds the "context" (i.e. filename and ideally also
>> the approximate file position info) to errors.
>> [ This may require something like `handler-bind`.  ]
> Another solution would be to dispense with
> display-byte-compile-warnings, just letting compiler errors generate
> backtraces.
>
> The problem here is that there is no distinction in bytecomp.el between
> "external" errors (such as from require) and errors detected by the
> compiler in the source file being compiled.

These are two fairly "clear" cases, admittedly.

But there are also cases in between where it's less clear, mostly with
errors during macro-expansion where the internal/external distinction is
not always that clear since some macros come from outside but others
come from the very file we're compiling, and where we can't easily tell
if an error is due to a bug in the macro definition or a bug in the use
of the macro.

> The first decidedly want a backtrace, the second probably not.
> All these errors are handled as though they were "internal" errors
> detected by the compiler.  This is suboptimal.

Also there are 2 questions:

- whether to give a backtrace (and/or enter the debugger).
- when we don't show a backtrace, what info do we put in the error message.

For the first, the current "solution" is to set `byte-compile-debug`.
It's not ideal, and we should improve it, but at least we do have
a solution for it.

For the second we currently don't show a good enough info and in my
previous response I focused on that part.

> Perhaps we should report the second type of error (detected by the
> compiler) by calling a warning function, as we do for warnings, and
> removing the damaging condition-case's as suggested two paragraphs back.

If the user is not asking to see backtraces, the current treatment seems
cleaner than without any `condition-case`.  So maybe those
`condition-case` should be turned into `condition-case-unless-debug`?


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 12 Nov 2023 20:43:01 +0000
Resent-Message-ID: <handler.66912.B66912.16998217573477 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.16998217573477
          (code B ref 66912); Sun, 12 Nov 2023 20:43:01 +0000
Received: (at 66912) by debbugs.gnu.org; 12 Nov 2023 20:42:37 +0000
Received: from localhost ([127.0.0.1]:57103 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r2HHx-0000u0-ED
	for submit <at> debbugs.gnu.org; Sun, 12 Nov 2023 15:42:37 -0500
Received: from mail.muc.de ([193.149.48.3]:38573)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1r2HHs-0000tj-HX
 for 66912 <at> debbugs.gnu.org; Sun, 12 Nov 2023 15:42:36 -0500
Received: (qmail 91819 invoked by uid 3782); 12 Nov 2023 21:41:43 +0100
Received: from acm.muc.de (pd953a91f.dip0.t-ipconnect.de [217.83.169.31])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Sun, 12 Nov 2023 21:41:43 +0100
Received: (qmail 25620 invoked by uid 1000); 12 Nov 2023 20:41:39 -0000
Date: Sun, 12 Nov 2023 20:41:39 +0000
Message-ID: <ZVE4gyjaCQdw0sbf@ACM>
References: <ZUTaWfQQuGET2Fb2@ACM> <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
 <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Sun, Nov 12, 2023 at 12:28:13 -0500, Stefan Monnier wrote:
> > Why not?  We're not in the compilation any more, we're loading a file.
> > Some error has prevented that file loading, so we want a backtrace just
> > as we would get with M-x load-file foo.elc RET.

> Hmm... that's a good point.

> >> I think for this specific problem being discussed (which is indeed
> >> a fairly common occurrence in my experience), the better solution is to
> >> change `load` so it adds the "context" (i.e. filename and ideally also
> >> the approximate file position info) to errors.
> >> [ This may require something like `handler-bind`.  ]
> > Another solution would be to dispense with
> > display-byte-compile-warnings, just letting compiler errors generate
> > backtraces.

> > The problem here is that there is no distinction in bytecomp.el between
> > "external" errors (such as from require) and errors detected by the
> > compiler in the source file being compiled.

> These are two fairly "clear" cases, admittedly.

> But there are also cases in between where it's less clear, mostly with
> errors during macro-expansion where the internal/external distinction is
> not always that clear since some macros come from outside but others
> come from the very file we're compiling, and where we can't easily tell
> if an error is due to a bug in the macro definition or a bug in the use
> of the macro.

Question: will the user be able to identify the macro and its source
file if we just print the bare error message as enforced by
displaying-byte-compile-warnings?  It the answer is no or not really, we
should give her the backtrace to get started on.

> > The first decidedly want a backtrace, the second probably not.
> > All these errors are handled as though they were "internal" errors
> > detected by the compiler.  This is suboptimal.

> Also there are 2 questions:

> - whether to give a backtrace (and/or enter the debugger).
> - when we don't show a backtrace, what info do we put in the error message.

> For the first, the current "solution" is to set `byte-compile-debug`.
> It's not ideal, and we should improve it, but at least we do have
> a solution for it.

I suspect byte-compile-debug isn't widely known.  Its name is also a bit
discordant - it's not necessarily about debugging byte-compile, it's
just to get sensible error messages when something goes wrong,
especially when that something is not part of the byte compiler.

> For the second we currently don't show a good enough info and in my
> previous response I focused on that part.

Indeed, for the error message which provoked this bug report, the
current information is poor indeed.  Considering that require's can be
nested, we only tell the user the identity of the outermost one.

> > Perhaps we should report the second type of error (detected by the
> > compiler) by calling a warning function, as we do for warnings, and
> > removing the damaging condition-case's as suggested two paragraphs back.

> If the user is not asking to see backtraces, the current treatment seems
> cleaner than without any `condition-case`.

It's "neat and tidy", but at the cost of discarding all useful
information.  There are other common situations in Emacs where
the debugger is entered, or a backtrace output without debug-on-error
having to be set.  Perhaps this one should join them.

> So maybe those `condition-case` should be turned into
> `condition-case-unless-debug`?

I think this would be a very useful first step.  I think it likely a
user will set debug-on-error on encountering any unhelpful error
message.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 12 Nov 2023 21:21:01 +0000
Resent-Message-ID: <handler.66912.B66912.16998240347554 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.16998240347554
          (code B ref 66912); Sun, 12 Nov 2023 21:21:01 +0000
Received: (at 66912) by debbugs.gnu.org; 12 Nov 2023 21:20:34 +0000
Received: from localhost ([127.0.0.1]:57151 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r2Hsc-0001xi-LC
	for submit <at> debbugs.gnu.org; Sun, 12 Nov 2023 16:20:33 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31038)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1r2HsY-0001xS-F6
 for 66912 <at> debbugs.gnu.org; Sun, 12 Nov 2023 16:20:29 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BE358801D4;
 Sun, 12 Nov 2023 16:19:38 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1699823977;
 bh=/loNEui/viZvwhh6UI9dWfynRmX8bL6Sc3r1N4bR1qc=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=dZFlRL8DEhrwGtG8DA1LGbXOfd5THX9qPP9sAIIEAFk1onPlqYzkVEKsHKfAms+LO
 Wr5iXodE3z1Xh4JnRW4YtvtZgStSoZqKIabWNnu7sdlM5xoKj0YEVmDx+OqXOfGKUI
 KscHRmyH0StVmgwI3a70vymKAPS4/yqGHUK0lxjKiMiWvs2raVmdev6KZYl05aTcqJ
 55iSgtDxb9O+UaX5I4Zej3sfuBAqU+TwHaFLhDZwSyWXL/7YvPsTnQ6ppWxkTEPgB2
 8y9PbzAdEG9uM0XuD157X1P5iHPJgPEaUiTpJnX9brSSIAmLVYW0y6Z3UHVvNp0xJe
 DgwWicBfYXR0A==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C68CB80578;
 Sun, 12 Nov 2023 16:19:37 -0500 (EST)
Received: from pastel (unknown [45.72.227.120])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9D0F3120209;
 Sun, 12 Nov 2023 16:19:37 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZVE4gyjaCQdw0sbf@ACM> (Alan Mackenzie's message of "Sun, 12 Nov
 2023 20:41:39 +0000")
Message-ID: <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
References: <ZUTaWfQQuGET2Fb2@ACM> <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
 <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
 <ZVE4gyjaCQdw0sbf@ACM>
Date: Sun, 12 Nov 2023 16:19:36 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.016 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> But there are also cases in between where it's less clear, mostly with
>> errors during macro-expansion where the internal/external distinction is
>> not always that clear since some macros come from outside but others
>> come from the very file we're compiling, and where we can't easily tell
>> if an error is due to a bug in the macro definition or a bug in the use
>> of the macro.
>
> Question: will the user be able to identify the macro and its source
> file if we just print the bare error message as enforced by
> displaying-byte-compile-warnings?

I think we print a "bare" error message (together with the location of
the macro call).  Often it's good enough (e.g. when the error is really
in the macro call itself).  Sometimes it's very perplexing :-(

> It the answer is no or not really, we should give her the backtrace to
> get started on.

Says the one who claimed earlier that backtraces are stressful :-)

Dumping the backtrace is a kind of cop-out.

Don't get me wrong, I love backtraces, but I don't think we should
blissfully throw backtraces at unsuspecting users (unlike Python, say).
IOW, we should first work harder to provide better error messages.

>> For the first, the current "solution" is to set `byte-compile-debug`.
>> It's not ideal, and we should improve it, but at least we do have
>> a solution for it.
>
> I suspect byte-compile-debug isn't widely known.  Its name is also a bit
> discordant - it's not necessarily about debugging byte-compile, it's
> just to get sensible error messages when something goes wrong,
> especially when that something is not part of the byte compiler.

Agreed.

>> For the second we currently don't show a good enough info and in my
>> previous response I focused on that part.
> Indeed, for the error message which provoked this bug report, the
> current information is poor indeed.  Considering that require's can be
> nested, we only tell the user the identity of the outermost one.

We don't even give that info.  We just give the line number of the
`require`.  It's almost as good as the outermost file name, but not quite.

> It's "neat and tidy", but at the cost of discarding all useful
> information.  There are other common situations in Emacs where
> the debugger is entered, or a backtrace output without debug-on-error
> having to be set.

Hmm... I can't think of such a situation.  When/where do we show
a backtrace without the user's explicit request?

>> So maybe those `condition-case` should be turned into
>> `condition-case-unless-debug`?
> I think this would be a very useful first step.  I think it likely a
> user will set debug-on-error on encountering any unhelpful error
> message.

AFAICT this would basically be equivalent to aliasing
`byte-compile-debug` to `debug-on-error`.

It may turn out to be annoying occasionally, but I think it's worth
a try (I've never found it useful to have `byte-compile-debug` set to
t without also setting `debug-on-error` to t).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Drew Adams <drew.adams@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 12 Nov 2023 23:01:02 +0000
Resent-Message-ID: <handler.66912.B66912.169983005428069 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>, Alan Mackenzie <acm@HIDDEN>
Cc: "66912 <at> debbugs.gnu.org" <66912 <at> debbugs.gnu.org>
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.169983005428069
          (code B ref 66912); Sun, 12 Nov 2023 23:01:02 +0000
Received: (at 66912) by debbugs.gnu.org; 12 Nov 2023 23:00:54 +0000
Received: from localhost ([127.0.0.1]:57226 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r2JRl-0007If-JZ
	for submit <at> debbugs.gnu.org; Sun, 12 Nov 2023 18:00:54 -0500
Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:44836)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1r2JRh-0007IR-7A
 for 66912 <at> debbugs.gnu.org; Sun, 12 Nov 2023 18:00:52 -0500
Received: from pps.filterd (m0246617.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id
 3ACMHHsW011585; Sun, 12 Nov 2023 23:00:06 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2023-03-30;
 bh=GdIT3h9hNquIzi5w/JrsjKuMzqoSmOSGUYhGzKV6Vmg=;
 b=erGOWjfC1/maXeKP2TJwDBVUzT9EydArd/WItRK4whP/2v268L5LS5DwZGsUwkpwXL5y
 H6XRZZdzSlhlpLeKmYfNUDWNZlinXYq4MmcT9OW/0iUSlafaQn7b70Mo1BBX/TpGwh5v
 GYpqR1wcFoWmA03ohiC5BQj0vZOFgTjFs/jpFsidDgE1OkGq0GMWF2cuydeR+IsxVRzk
 z9RCdj4UTk5rp0pwWOMoMbVODP4DT7iWYYmQymfTwlzoXv5WdPXqUZJ8AL4RI09IeZlZ
 Wk0eAN0JYCa5er1DFJERt5hdp87EC0jhjbrcfCnloFob8T41CIlcGQw2PdaVOL9ZetUm Lg== 
Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta01.appoci.oracle.com [138.1.114.2])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3ua2sthqxc-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sun, 12 Nov 2023 23:00:05 +0000
Received: from pps.filterd
 (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19)
 with ESMTP id 3ACLo25k020846; Sun, 12 Nov 2023 23:00:05 GMT
Received: from nam11-co1-obe.outbound.protection.outlook.com
 (mail-co1nam11lp2169.outbound.protection.outlook.com [104.47.56.169])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 3uaxgy1gj0-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sun, 12 Nov 2023 23:00:05 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=dhU3+6hUTNYBwsxO50V1ex/f2xdXYU6iaU815xCuFpNufX+rd/cD4KtqbR/ailVM70NoF995W0K5/Md/fQKz6D+vUfChcftDKLV8uDyAXH8s1DQmo2yNPnt7IvgJjdN2eAP/J5MX0MH8QCByNGJJGv1oBppi+gQHdADNvuU3JFKzFWFVHFlLrz361j42kwb2tVb/G59mVI3vVk3DknmBDTySUP2EHPMcEGgmxUYMZUGNLChN5F5iPz3M8MjhmUqO6vZt71bO1JRX0bxeBkCF8kp16VDnf1K95odDzfOlJ1n/uis9C13Av684cH+QFo7aY7hj3Fw1zBqMF27jjOzpRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GdIT3h9hNquIzi5w/JrsjKuMzqoSmOSGUYhGzKV6Vmg=;
 b=ZaMaQqdHge7iDWTuCuDwpWETsNCdGt8sbG9HxVPtz0VaEK19gJ6LJ5aGpvwZeBtMRPxumCqhZGSSXOWmgKk5m69NtAyp//gojQzxqCpTexE6wlA6ee5WV6JZOcZ2RbND9Gw6PaiwN640vIEcnnHUVd2a6YqGNKkHcyIGKLcrWisekMbBoPNszCK90WXzOpT7k9/dJZ7qZIBYPgpQIfvPDOles3cp80+0NXalaDGGpMURmUbe+kiPGX3Vl0MSzjFSadGQk9RuGyAGtoh+QLNNVEHeF/5eMuHdu/Wb4I8JUC3cwXnXRo83tw9Rph4Xx/F2R0hqVAQoxkeTftRT1li6qQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=GdIT3h9hNquIzi5w/JrsjKuMzqoSmOSGUYhGzKV6Vmg=;
 b=G6NqEWL/00yWuKs+4UsBlJxvDusJGI55ATz7A9konfU2ospf4UV6tgiNDC84h2eOcfKCI+uSNz0cpaQ8uKhhkZhFSCgc3Hlk/ebJaPaCj4Zvjv6MldClTBSj+yz6N2A/FQTlDQ4jVsQi80ObqfrVyLH6O1mEyzdAEmi442NF57E=
Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19)
 by PH7PR10MB6155.namprd10.prod.outlook.com (2603:10b6:510:1f4::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6977.28; Sun, 12 Nov
 2023 23:00:03 +0000
Received: from SJ0PR10MB5488.namprd10.prod.outlook.com
 ([fe80::3b4c:a669:c229:47b4]) by SJ0PR10MB5488.namprd10.prod.outlook.com
 ([fe80::3b4c:a669:c229:47b4%6]) with mapi id 15.20.6977.028; Sun, 12 Nov 2023
 23:00:03 +0000
From: Drew Adams <drew.adams@HIDDEN>
Thread-Topic: [External] : bug#66912: With `require', the byte compiler
 reports the wrong file for errors.
Thread-Index: AQHaFajRvNMt81NI40e0xNfi6854brB3MOSXgAAYgjA=
Date: Sun, 12 Nov 2023 23:00:02 +0000
Message-ID: <SJ0PR10MB54883E6D3C67431F2D26C5E5F3ACA@HIDDEN>
References: <ZUTaWfQQuGET2Fb2@ACM> <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
 <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
 <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SJ0PR10MB5488:EE_|PH7PR10MB6155:EE_
x-ms-office365-filtering-correlation-id: f4a650bc-bc20-4907-eac5-08dbe3d31acd
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: mvxmFqf2YJXq0amIXe+OCq/1TuPMINh1zBKCM8PsrwFnIMwDV29L1/pH0bha6eSyDzLWR7+9Vsq/j7caKHnbZrE/2BDGVNOnh5iLnrM1sMyOjZ/9usYLms3k3HOpjJHH53VaB1cp+W6pPmNXaHSbAZ0cBz8FAJnwmihciB6IFExpNBbS1ooRsWHiuJOWmizrouyE46XMNPU4/hRnmHb8IITcxZ/53mVlbg0uQ6MHZvCGAQo9xj7z/7tgmM0Tfh1sojyh2L6a00dvR56dliXbseA5LUpXVRV2y2MCJ4v5kph63R7ttjhnnyBLmzzZhrqQ4r+Pp4ezn+ox2wMaa0Er15/P+d+Z1ZYI/ycfLueLOrMW9aoUANi1M6eiFkbzmVSrZhmgsqYJuYtFqkwAi5NRACwz7QBtofwHWKc9iwfq+lYH4/nJt3uXMmWQNMLucD9f0p3/1MZHSag3lLX4/Ij4kFDelg/er4y9Z+pwch3FfnBI/9N62B5rkEWKJER0csFhnbeecD4Zxupd4M+GiEaJgFQ4UZgQFfzTi6JB2Rh13uBX+woGXQY4GCsqvEsdyrKgbrIrwOI9muQW+/42R0jpJNtOSnwvRxhD2rxz2FiCMaBD4smINBuQMXmwel3s6tAPTi21nAPhOfkpaqARspA22w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(13230031)(396003)(366004)(136003)(346002)(376002)(39860400002)(230922051799003)(451199024)(64100799003)(186009)(1800799009)(44832011)(4326008)(8676002)(8936002)(52536014)(71200400001)(38070700009)(26005)(2906002)(5660300002)(86362001)(7696005)(6506007)(55016003)(33656002)(122000001)(478600001)(41300700001)(38100700002)(83380400001)(296002)(316002)(9686003)(66946007)(66556008)(66446008)(64756008)(66476007)(76116006)(110136005)(81973001);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: KYyuSexBfop1lwc694dHCY0FEIpBD7zzZCcV+ZcHWPaz8AVbUBnv33NueWl9zkNo9cWapxwgKnQJaKWJVfcHxmQtFYfQzaZ8wuYuK96gYqXHMHJeFvmXjLkgT2PhAzHHtKvH3r+mGAjK4w+iFolcp1aR458/ZTRXR6cCck17cBH+mu7AzpapUyqnnF76CXi34fekCzwDv9XSWebujiiyNb0I9m38Tarcez57lpnnr7cLtVzVCPTMCPgmy6eBx788ynyIhNnQd2Dbmwz8ITzGyStlV+gH+TwZWXVJcB8wLsxk/zx6R/HeTTbC/tTRsaMkx0SLJx2zql4/MnS6Sa/gkhYPGY2gpa3DfQjy0f7zxF3oLo97cOTLJKWx4hS4RB2pHsY+fEIoj/Nx1MM0CFs/eriPI21YRln3B79e5/tETz51SMR3RgXtTRWzVVfQQwfGRIlhpIPV8JHqSQu4EiLMf4sA6TQkVpdX5q2HZW83rviiIkjYMF9bcDPY9QvmnGBtZqh/MPAm78mA+X5EZ9BMfedyiVP3BU1yBJQARIuLflbkvZXcYVS5svnK1TTugAeVZWlIle0RRSxErvjaiuKofa5IfsLBBc+pZHRJ5sIqeGdUrywWyZuDZ4+WPSZj4MwR3rcnBCBDAv2nbdRWIhbSgerJ4zEJPnlKER/xtGkk4ivV3Dd656cBy0y1e2tPT3M/zQQpQYjjLRX/b+W/1aDEsrtfUbySmAkBLjtVzWrYkp8kKdXADuRWP17NeUFf7svFVtWmr5T3EmMw16uGeRotqnmOy/h6P3n/IWHfd1CYwNOOfiqvhCifHJhO2mc+6HWzyJQhVLLIACJJMUAWZxu0yjibWq9Fv6nvy3DYTCHGU+Y+o1k+8nDgXdMNQqh+6NMrhcqhqadxyhCokKIreK/qBBuNq2ztPxAAUzqjIe0FmaYarhrS2gb3iEm0qugzQ+/Y3w3di6fvHWj5LZowoL0rnKR1pqHGtxMlSqP8QpZm9kzv04oL8yUqn7M3Ysr+BFsBkLC77M26nBjwz52WMiRf3EUGOACZ97HWcI+ytIPJ6LN9ROKOlq9LaNs4xq84v/ZAppPPzZPE717tXQi5CQKPrX++SMNSSg4vrPr47tIsRpn/rFOZdNKp1gxOfqJeG7oLZHH0sZ2jH1VDhKtBLmVoloZqQIvGpVkAz1ODEfZt0Q5NmIv8GPLfSn3HAqtNdq9c0Dm/5NhRHrw6TMB6cYFy7o2nVFiSRXajV2v33oRKNynTKzIeC1orWzzXKj1Va7bqTvnrV1nITCd4zXCGf5dt74OqdKEIKFJHP2F7G9kawa3Tk3nrqftWuVdwnj6bWAmVdz/25oB9pblykt7XJKRsX9izi9lEQnz4qceC9qefyqKb0YdMIzu9Muf8GeIYtgKOqrbYcoXANCCnFEQ7YG64RRBIhu0SEpJ/R0Bx8S6Z9KPW5I8u1SaFz1Ab32ZHBU0y/TAc4CsXt3fh+7/Z/f9pi2Exw1GUlEmsYuGy/GnfOd4YqfEQEZ3Dv+9L+xy3eRI9izG4KMCtIUi/2nwEftsTpMSDRzhp7Jlb9F4XyOeGjhvK8I12Qc/gyi6MNLSr1dOD
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 9NeywDfd8K5SxIJwSabnRq4ZY6++y2vslJFPLO/fDfv2jYCc5cj2ZqqCFe6ZvmcQbvvy7a7vAuB46FQQzwD4NqjKjPtvkhJAuNAf7AC3hbUZyPJWFMR/2Oe2t1GiEPeiDpyzXG2a5NqqozrrMW++hRVL5Gj2yEY4Ow8K1Ay9Kl3C+DJepwbi++yFWakEqYKEAdEk79uCw4S0oR5VJPp8szFI8lg2dh2c2MLN73EsRs32+M0I5KjdB3HCLaaii1CRrrWa3bW0YM6qxrPt4cBF9SyCLK7c/6Qy1axv9rAHVG3UJOmbY15O6c7PenHKHsUPGAPBE/Na8yD1LjfUvquVoXw+yBO7Utt2U1Wh+t2+9nYtkc1+xyOY/Ara9nYD0DKYVeDbICL6ybjeuY/ThUEsvEtmx55ed9bcieBQDRPk2kcHbGm5oKp0EjnB+6zplgpT3+5CQaWF050D8Ukd60nvVzWzEKvPv9YmgkAKDLxAoiuAtUk25seVLMLw/NnCg8vggUr2J5Eyv8wPg5S6m0tuildHZ42sWo+JV6Xae5EsFka7VPflBIeEao38Mv6JBFRwAJCjoWBFx2Tco/Zy4xJZFYIotx16njCROh777D4IwmvW0McCggF+jzTxHPHuxuRu8uGlUzXxFeH3OWuWju1txKduMDt1FtG2wXtXz7rWZECEXal+NmVoyPg8dDUShe62iOYqCryxFV2U8hqYn+t+r6Wr4ye9QWS54qocPWE1iLnDXAoVLwCXtLerxG+8OJkyrah3q/42VitKvERgLbP5NLo9h+CtcYKnErdI2/CwCcm/QPoJR+b5AU/28RBKdvn4VkY9U206IZ7jl/ozCo7+hA==
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f4a650bc-bc20-4907-eac5-08dbe3d31acd
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2023 23:00:02.9746 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: eRQNQjIbnAXbMoGXAMXPPbxwtNf+8XxePY9CePKUcIUcw3LOoHgAa+2XQ8b+rwTWowepGC+k2hRseKmKVBsWww==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB6155
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2023-11-12_22,2023-11-09_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 bulkscore=0
 malwarescore=0 phishscore=0 mlxlogscore=999 adultscore=0 mlxscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2311060000 definitions=main-2311120202
X-Proofpoint-GUID: 5PDeV-44BJQcS33PrRHfGb_ftPTY4W0x
X-Proofpoint-ORIG-GUID: 5PDeV-44BJQcS33PrRHfGb_ftPTY4W0x
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> Dumping the backtrace is a kind of cop-out.
>=20
> Don't get me wrong, I love backtraces, but I don't think we should
> blissfully throw backtraces at unsuspecting users (unlike Python, say).
> IOW, we should first work harder to provide better error messages.

OT, so ... sorry.

It just occurred to me that instead of just having
a Boolean `debug-on-error', which turns use of the
debugger on/off for an error, there might be a
third possibility: show an error message and let
you then decide whether to open the backtrace --
maybe click (or `RET') the error msg, or in some
other way make the choice.

IOW, we could perhaps prepare a backtrace buffer
without actually entering its recursive edit etc.
If a user doesn't ask to see/use it then it just
sits there (buried) as an unused buffer.

Or display of the error msg could allow for (1)
activating/entering the backtrace buffer, (2)
leaving it buried, or (3) deleting it.

No idea about implementation or reasonableness.
Just something that occurred to me.  Yes, first
priority should be a good error msg.  Yes, users
should be able to optionally open the debugger.
But could we maybe  give them that possibility
after showing the error msg?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 29 Oct 2024 19:00:02 +0000
Resent-Message-ID: <handler.66912.B66912.173022836225765 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173022836225765
          (code B ref 66912); Tue, 29 Oct 2024 19:00:02 +0000
Received: (at 66912) by debbugs.gnu.org; 29 Oct 2024 18:59:22 +0000
Received: from localhost ([127.0.0.1]:58150 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t5rR4-0006hU-5y
	for submit <at> debbugs.gnu.org; Tue, 29 Oct 2024 14:59:22 -0400
Received: from mail.muc.de ([193.149.48.3]:15979)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t5rR1-0006hN-Ik
 for 66912 <at> debbugs.gnu.org; Tue, 29 Oct 2024 14:59:20 -0400
Received: (qmail 43641 invoked by uid 3782); 29 Oct 2024 19:59:12 +0100
Received: from muc.de (p4fe1578b.dip0.t-ipconnect.de [79.225.87.139]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Tue, 29 Oct 2024 19:59:12 +0100
Received: (qmail 24373 invoked by uid 1000); 29 Oct 2024 18:59:11 -0000
Date: Tue, 29 Oct 2024 18:59:11 +0000
Message-ID: <ZyEwfwDHEenwpkkr@HIDDEN>
References: <ZUTaWfQQuGET2Fb2@ACM> <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
 <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
 <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

It's been almost a year since this bug got lost in the storm of other
things which needed doing.  I'd like to come back to it now.  To refresh
your memory, the problem was about not getting any information about foo
when an error occurred during (require 'foo).

And no apologies for the top posting, which just seems appropriate,
since new possibilities (handler-bind in particular, thanks!) have
appeared in the last year.

My latest idea is to put (the C equivalent of) handler-bind around the
readevalloop call near the end of Fload.  So with my test files from last
year, in place of the current error output 

    test-byte-compile-errors.el:2:11: Error: Wrong type argument: listp, baz

the following line would appear:

    test-byte-compile-errors.el:2:11: While loading "test-byte-compile-errors-2.el" Error: Wrong type argument: listp, baz

..  The "While loading "foo.el" " bit would be repeated as needed for
nested (require 'foo)s.  OK, the error line could be quite long, but the
information would at least be there.

This could surely be achieved with something like the following in Fload:

    (handler-bind ((lambda (err)
                    (signal (car err)
		            (combine-error-info "While loading " file
			                         (cdr err)))))
		  readevalloop (Qget_file_char, &input, hist_file_name,
		      0, Qnil, Qnil, Qnil, Qnil);)

(where, obviously, the details need to be worked out).  It would need
augmenting with handling for (eq debug-on-error t), and probably a few
other things, too.

What do you think of the idea?

-- 
Alan Mackenzie (Nuremberg, Germany).


On Sun, Nov 12, 2023 at 16:19:36 -0500, Stefan Monnier wrote:
> >> But there are also cases in between where it's less clear, mostly with
> >> errors during macro-expansion where the internal/external distinction is
> >> not always that clear since some macros come from outside but others
> >> come from the very file we're compiling, and where we can't easily tell
> >> if an error is due to a bug in the macro definition or a bug in the use
> >> of the macro.

> > Question: will the user be able to identify the macro and its source
> > file if we just print the bare error message as enforced by
> > displaying-byte-compile-warnings?

> I think we print a "bare" error message (together with the location of
> the macro call).  Often it's good enough (e.g. when the error is really
> in the macro call itself).  Sometimes it's very perplexing :-(

> > It the answer is no or not really, we should give her the backtrace to
> > get started on.

> Says the one who claimed earlier that backtraces are stressful :-)

> Dumping the backtrace is a kind of cop-out.

> Don't get me wrong, I love backtraces, but I don't think we should
> blissfully throw backtraces at unsuspecting users (unlike Python, say).
> IOW, we should first work harder to provide better error messages.

> >> For the first, the current "solution" is to set `byte-compile-debug`.
> >> It's not ideal, and we should improve it, but at least we do have
> >> a solution for it.

> > I suspect byte-compile-debug isn't widely known.  Its name is also a bit
> > discordant - it's not necessarily about debugging byte-compile, it's
> > just to get sensible error messages when something goes wrong,
> > especially when that something is not part of the byte compiler.

> Agreed.

> >> For the second we currently don't show a good enough info and in my
> >> previous response I focused on that part.
> > Indeed, for the error message which provoked this bug report, the
> > current information is poor indeed.  Considering that require's can be
> > nested, we only tell the user the identity of the outermost one.

> We don't even give that info.  We just give the line number of the
> `require`.  It's almost as good as the outermost file name, but not quite.

> > It's "neat and tidy", but at the cost of discarding all useful
> > information.  There are other common situations in Emacs where
> > the debugger is entered, or a backtrace output without debug-on-error
> > having to be set.

> Hmm... I can't think of such a situation.  When/where do we show
> a backtrace without the user's explicit request?

> >> So maybe those `condition-case` should be turned into
> >> `condition-case-unless-debug`?
> > I think this would be a very useful first step.  I think it likely a
> > user will set debug-on-error on encountering any unhelpful error
> > message.

> AFAICT this would basically be equivalent to aliasing
> `byte-compile-debug` to `debug-on-error`.

> It may turn out to be annoying occasionally, but I think it's worth
> a try (I've never found it useful to have `byte-compile-debug` set to
> t without also setting `debug-on-error` to t).


>         Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 30 Oct 2024 19:34:01 +0000
Resent-Message-ID: <handler.66912.B66912.173031679523596 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173031679523596
          (code B ref 66912); Wed, 30 Oct 2024 19:34:01 +0000
Received: (at 66912) by debbugs.gnu.org; 30 Oct 2024 19:33:15 +0000
Received: from localhost ([127.0.0.1]:37033 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t6ERP-00068W-8M
	for submit <at> debbugs.gnu.org; Wed, 30 Oct 2024 15:33:15 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60871)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t6ERM-00068O-Mq
 for 66912 <at> debbugs.gnu.org; Wed, 30 Oct 2024 15:33:13 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id F280E442856;
 Wed, 30 Oct 2024 15:33:05 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1730316784;
 bh=jXDK0QTlSaJ9zM//biyL3BA8hpfvp6Reu3D++88Z28A=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=bUDMQU33maPuQ0XhT7t8yDsJcGvSQ/T5HCCh5UFY5ELjyGAWUgThhxEG890+wi3mq
 bzaLkNCUYC1/JZ5CXDT+e+cCJNT+gsGQlauvk5fXAglRsFR4u8vehKWMnKbOkMZKuU
 STuaOY1IpamXw7mG0MbGsPlVYA+i7cVNwI9RQDXcgAEVJqRruslHK0pz34QXZDLugc
 2r3Lx+eLmUcmezf7Mb0x7T/zsjxQYOUW+hIZl/UNKw0cqT3Z1+RPFozyz4t1HTjOpD
 ZWywoxTO/BKegn+BBlE/2yN8lNqlQE5cbn4+HqVK1r6F93jSdTORPQmurRpw30vXsD
 bHHGSHGPsHjGQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BB28A44285E;
 Wed, 30 Oct 2024 15:33:04 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9F51112033B;
 Wed, 30 Oct 2024 15:33:04 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZyEwfwDHEenwpkkr@HIDDEN> (Alan Mackenzie's message of
 "Tue, 29 Oct 2024 18:59:11 +0000")
Message-ID: <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
References: <ZUTaWfQQuGET2Fb2@ACM> <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
 <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
 <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
Date: Wed, 30 Oct 2024 15:33:04 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.209 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> year, in place of the current error output 
>
>     test-byte-compile-errors.el:2:11: Error: Wrong type argument: listp, baz
>
> the following line would appear:
>
>     test-byte-compile-errors.el:2:11: While loading "test-byte-compile-errors-2.el" Error: Wrong type argument: listp, baz

I can definitely live with this syntax, but maybe we should use
something more like what GCC uses (e.g. for errors in #included files)
which puts the "While loading" info on separate lines.

> This could surely be achieved with something like the following in Fload:
>
>     (handler-bind ((lambda (err)
>                     (signal (car err)
> 		            (combine-error-info "While loading " file
> 			                         (cdr err)))))
> 		  readevalloop (Qget_file_char, &input, hist_file_name,
> 		      0, Qnil, Qnil, Qnil, Qnil);)

That was my thinking as well (tho see below).

> (where, obviously, the details need to be worked out).  It would need
> augmenting with handling for (eq debug-on-error t), and probably a few
> other things, too.

`combine-error-info` is a bit problematic because we don't have clear
rules about the content of (cdr err), other than the fact that it should
be a list (tho we don't even enforce that very much).
Most likely we could append elements to that list, but we'd have to
worry about interactions with other libraries wanting to do similar
things.

So I was thinking that we should go instead with:

   (handler-bind ((error (lambda (err)
                           (push file (gethash err our-table-of-error-source)))))
     	  readevalloop (Qget_file_char, &input, hist_file_name,
     	      0, Qnil, Qnil, Qnil, Qnil);)

Where `our-table-of-error-source` would be a weak eq-hashtable.
Emacs Lisp guarantees that the `err` we get here will be the exact same
object that any subsequent `condition-case` will get when it finally
handles the error so that it can use `gethash` to fetch our
side information.

Note that we don't `signal` the error again, instead we let the error
handling code propagate it further, which is what `handler-bind` does
when the handler returns normally (which should also eliminate the
possible problems of interaction with `debug-on-error`).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 30 Oct 2024 21:53:02 +0000
Resent-Message-ID: <handler.66912.B66912.17303251458841 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17303251458841
          (code B ref 66912); Wed, 30 Oct 2024 21:53:02 +0000
Received: (at 66912) by debbugs.gnu.org; 30 Oct 2024 21:52:25 +0000
Received: from localhost ([127.0.0.1]:37739 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t6Gc5-0002IX-3E
	for submit <at> debbugs.gnu.org; Wed, 30 Oct 2024 17:52:25 -0400
Received: from mail.muc.de ([193.149.48.3]:59143)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t6Gc2-0002IL-1U
 for 66912 <at> debbugs.gnu.org; Wed, 30 Oct 2024 17:52:22 -0400
Received: (qmail 54852 invoked by uid 3782); 30 Oct 2024 22:52:13 +0100
Received: from muc.de (pd953a184.dip0.t-ipconnect.de [217.83.161.132]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Wed, 30 Oct 2024 22:52:13 +0100
Received: (qmail 15004 invoked by uid 1000); 30 Oct 2024 21:52:13 -0000
Date: Wed, 30 Oct 2024 21:52:13 +0000
Message-ID: <ZyKqjSkBma6OQRJn@HIDDEN>
References: <ZUTaWfQQuGET2Fb2@ACM> <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
 <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
 <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Wed, Oct 30, 2024 at 15:33:04 -0400, Stefan Monnier wrote:
> > year, in place of the current error output 

> >     test-byte-compile-errors.el:2:11: Error: Wrong type argument: listp, baz

> > the following line would appear:

> >     test-byte-compile-errors.el:2:11: While loading "test-byte-compile-errors-2.el" Error: Wrong type argument: listp, baz

> I can definitely live with this syntax, but maybe we should use
> something more like what GCC uses (e.g. for errors in #included files)
> which puts the "While loading" info on separate lines.

I thought about that, but seeing as how only one message at a time is
visible in the message area, we'd probably want to output one message
with embedded LFs, rather than several consecutive "While loading ..."s.

> > This could surely be achieved with something like the following in Fload:

> >     (handler-bind ((lambda (err)
> >                     (signal (car err)
> > 		            (combine-error-info "While loading " file
> > 			                         (cdr err)))))
> > 		  readevalloop (Qget_file_char, &input, hist_file_name,
> > 		      0, Qnil, Qnil, Qnil, Qnil);)

> That was my thinking as well (tho see below).

> > (where, obviously, the details need to be worked out).  It would need
> > augmenting with handling for (eq debug-on-error t), and probably a few
> > other things, too.

> `combine-error-info` is a bit problematic because we don't have clear
> rules about the content of (cdr err), other than the fact that it should
> be a list (tho we don't even enforce that very much).
> Most likely we could append elements to that list, but we'd have to
> worry about interactions with other libraries wanting to do similar
> things.

Do other libraries actually do such things?

> So I was thinking that we should go instead with:

>    (handler-bind ((error (lambda (err)
>                            (push file (gethash err our-table-of-error-source)))))
>      	  readevalloop (Qget_file_char, &input, hist_file_name,
>      	      0, Qnil, Qnil, Qnil, Qnil);)

> Where `our-table-of-error-source` would be a weak eq-hashtable.

Do we need a hash table when it's only going to have a few elements at
any time?  `require's rarely go more than 5 or 6 deep.  Why not just have
a simple dynamically bound list?  Or have I misunderstood what you mean?

> Emacs Lisp guarantees that the `err` we get here will be the exact same
> object that any subsequent `condition-case` will get when it finally
> handles the error so that it can use `gethash` to fetch our
> side information.

> Note that we don't `signal` the error again, instead we let the error
> handling code propagate it further, which is what `handler-bind` does
> when the handler returns normally (which should also eliminate the
> possible problems of interaction with `debug-on-error`).

The reason I suggested a signal call was so that the error information in
the successive ERRs would accumulate, rather than just being the fixed
ERR from the initial error.

And I think any call to the debugger on account of debug-on-error should
be in the innermost recursive `require', where the error is actually
signalled, so as to be of maximum use to the person debugging it.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 30 Oct 2024 22:32:01 +0000
Resent-Message-ID: <handler.66912.B66912.173032751513882 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173032751513882
          (code B ref 66912); Wed, 30 Oct 2024 22:32:01 +0000
Received: (at 66912) by debbugs.gnu.org; 30 Oct 2024 22:31:55 +0000
Received: from localhost ([127.0.0.1]:37927 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t6HEJ-0003bq-2p
	for submit <at> debbugs.gnu.org; Wed, 30 Oct 2024 18:31:55 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:35129)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t6HEH-0003bh-9U
 for 66912 <at> debbugs.gnu.org; Wed, 30 Oct 2024 18:31:54 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id ABE13444446;
 Wed, 30 Oct 2024 18:31:45 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1730327504;
 bh=SJtYuhkr0os8EW/w6xaA5+24umxcZCJGcP+LJjtdDbs=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=ZYj2FhR1rgUu2KyF8wL/6+kEOwu/VGid6oA02hJBm2zU5jjmKgGMlu5JExdDxQokb
 tdHkCRiNv4bggNGNwFIaeXpDC8JSYK+hWEhHJxswz9FbMVBhQZxGdQ2qVvyW888bHD
 pnCU902TIKiz3knhVcbdRXWKvQPEYZZS2b7UfS5T5TydYkMNsp3hvOCoIMsMIzMQb+
 tMV+xFUwsaCBIsC9gLeduvR5nYc/Lx4RHDrcW7bPGAVRZXqzOvyeoWHb8e9cf54FxG
 GXqw1ArncL0olaujL4ivRFCvBzmep0GjfiCymttC3LNY1llUKeCHBCkC+fam6563hz
 SmsRUPkP5kgAA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 082E8444444;
 Wed, 30 Oct 2024 18:31:44 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EBBD2120346;
 Wed, 30 Oct 2024 18:31:43 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZyKqjSkBma6OQRJn@HIDDEN> (Alan Mackenzie's message of
 "Wed, 30 Oct 2024 21:52:13 +0000")
Message-ID: <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
References: <ZUTaWfQQuGET2Fb2@ACM> <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
 <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
 <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
Date: Wed, 30 Oct 2024 18:31:35 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.208 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I can definitely live with this syntax, but maybe we should use
>> something more like what GCC uses (e.g. for errors in #included files)
>> which puts the "While loading" info on separate lines.
> I thought about that, but seeing as how only one message at a time is
> visible in the message area, we'd probably want to output one message
> with embedded LFs, rather than several consecutive "While loading ..."s.

I don't have an opinion on that.  I only care about the case where that
info ends up in a file or buffer, along with other warnings and errors,
such as when I do `make` or `byte-compile-file`.  Ideally I'd like to be
able to click on each "While loading" to be brought to the place of the
corresponding `require`.  And ideally this would work with the existing
entries of `compilation-error-regexp-alist`.

>> `combine-error-info` is a bit problematic because we don't have clear
>> rules about the content of (cdr err), other than the fact that it should
>> be a list (tho we don't even enforce that very much).
>> Most likely we could append elements to that list, but we'd have to
>> worry about interactions with other libraries wanting to do similar
>> things.
>
> Do other libraries actually do such things?

Currently, this would be the first, but since I added `handler-bind`
I've already felt like doing such things on a few occasions, so it's
only a question of time.

>> So I was thinking that we should go instead with:
>
>>    (handler-bind ((error (lambda (err)
>>                            (push file (gethash err our-table-of-error-source)))))
>>      	  readevalloop (Qget_file_char, &input, hist_file_name,
>>      	      0, Qnil, Qnil, Qnil, Qnil);)
>
>> Where `our-table-of-error-source` would be a weak eq-hashtable.
>
> Do we need a hash table when it's only going to have a few elements at
> any time?  `require's rarely go more than 5 or 6 deep.  Why not just have
> a simple dynamically bound list?  Or have I misunderstood what you mean?

A hashtable is not the only solution, indeed.  But a weak hashtable
makes it possible to skip the need to use something that's "dynamically
bound", and hence to have to think about where we do the dynamic binding
and what to do if it's nested etc...
IOW, it seems simpler to me.

>> Emacs Lisp guarantees that the `err` we get here will be the exact same
>> object that any subsequent `condition-case` will get when it finally
>> handles the error so that it can use `gethash` to fetch our
>> side information.
>
>> Note that we don't `signal` the error again, instead we let the error
>> handling code propagate it further, which is what `handler-bind` does
>> when the handler returns normally (which should also eliminate the
>> possible problems of interaction with `debug-on-error`).
>
> The reason I suggested a signal call was so that the error information in
> the successive ERRs would accumulate, rather than just being the fixed
> ERR from the initial error.

In my suggestion I also accumulate them, but I put them in the side-info
hashtable instead of inside the error object.  I think it is important to
preserve the `eq`ness of the error object (since it embodies the fact
that we're still handling the same error), so if we don't use a side
table we would probably want to "combine" by mutating the error object.

> And I think any call to the debugger on account of debug-on-error should
> be in the innermost recursive `require', where the error is actually
> signalled, so as to be of maximum use to the person debugging it.

I think I agree tho "be in the innermost recursive `require'" seems
quite vague.  But in any case the handlers of `handler-bind` are run
before we unwind the stack (e.g. if your nesting looks like "require =>
require => error" the two handlers of your two `require`s will be run
before we get to the debugger but the debugger will still show the full
stack.  Tho with your use of "resignaling" within the handlers, the
stack will tend to be even "more full", with the two handlers nested
and still active), so no matter how we do it, I think we will indeed get
the behavior that I believe you describe.

More concretely, with your code, I think the debugger will be called
with a stack that looks like

     <calling the debugger>
     signal(...)
     ...
     <calling the handler of the outer handler-bind>
     signal(...)
     ...
     <calling the handler of the inner handler-bind>
     error("the actual error")
     ...
     handler-bind(...)    ; the inner one
     require(...)
     ...
     handler-bind(...)    ; the outer one
     require(...)

whereas with the code I suggest the stack should look like

     <calling the debugger>
     error("the actual error")
     ...
     handler-bind(...)    ; the inner one
     require(...)
     ...
     handler-bind(...)    ; the outer one
     require(...)

In any case, it should be easy to try out and change from one to the
other with very local changes (I'd expect that the code of the handlers
will be written in ELisp rather than C, right?).  So either way is fine.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 02 Nov 2024 13:48:01 +0000
Resent-Message-ID: <handler.66912.B66912.173055524514452 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173055524514452
          (code B ref 66912); Sat, 02 Nov 2024 13:48:01 +0000
Received: (at 66912) by debbugs.gnu.org; 2 Nov 2024 13:47:25 +0000
Received: from localhost ([127.0.0.1]:53540 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t7ETM-0003l2-B3
	for submit <at> debbugs.gnu.org; Sat, 02 Nov 2024 09:47:24 -0400
Received: from mail.muc.de ([193.149.48.3]:22358)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t7ETK-0003ku-5U
 for 66912 <at> debbugs.gnu.org; Sat, 02 Nov 2024 09:47:23 -0400
Received: (qmail 22255 invoked by uid 3782); 2 Nov 2024 14:47:14 +0100
Received: from muc.de (p4fe154f5.dip0.t-ipconnect.de [79.225.84.245]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Sat, 02 Nov 2024 14:47:14 +0100
Received: (qmail 19201 invoked by uid 1000); 2 Nov 2024 13:47:12 -0000
Date: Sat, 2 Nov 2024 13:47:12 +0000
Message-ID: <ZyYtYBLLKqas8r7B@HIDDEN>
References: <ZUTaWfQQuGET2Fb2@ACM> <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
 <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
 <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Wed, Oct 30, 2024 at 18:31:35 -0400, Stefan Monnier wrote:
> >> I can definitely live with this syntax, but maybe we should use
> >> something more like what GCC uses (e.g. for errors in #included files)
> >> which puts the "While loading" info on separate lines.
> > I thought about that, but seeing as how only one message at a time is
> > visible in the message area, we'd probably want to output one message
> > with embedded LFs, rather than several consecutive "While loading ..."s.

> I don't have an opinion on that.  I only care about the case where that
> info ends up in a file or buffer, along with other warnings and errors,
> such as when I do `make` or `byte-compile-file`.

Indeed, it is a relatively small point, which can easily be changed once
we have working code.

> Ideally I'd like to be able to click on each "While loading" to be
> brought to the place of the corresponding `require`.  And ideally this
> would work with the existing entries of
> `compilation-error-regexp-alist`.

OK.  Again, I think this could easily be added once the basic code is in
place.

[ .... ]

> >> So I was thinking that we should go instead with:

> >>    (handler-bind ((error (lambda (err)
> >>                            (push file (gethash err our-table-of-error-source)))))
> >>      	  readevalloop (Qget_file_char, &input, hist_file_name,
> >>      	      0, Qnil, Qnil, Qnil, Qnil);)

> >> Where `our-table-of-error-source` would be a weak eq-hashtable.

> > Do we need a hash table when it's only going to have a few elements at
> > any time?  `require's rarely go more than 5 or 6 deep.  Why not just have
> > a simple dynamically bound list?  Or have I misunderstood what you mean?

> A hashtable is not the only solution, indeed.  But a weak hashtable
> makes it possible to skip the need to use something that's "dynamically
> bound", and hence to have to think about where we do the dynamic binding
> and what to do if it's nested etc...
> IOW, it seems simpler to me.

I don't think we need either.  In lread.c, there is already a static
variable Vloads_in_progress (which despite the name, is not visible in
Lisp).  This variable is a stack of the file names currently being
loaded.  We could surely just use this, and avoid code duplication.

[ .... ]

> >> Note that we don't `signal` the error again, instead we let the error
> >> handling code propagate it further, which is what `handler-bind` does
> >> when the handler returns normally (which should also eliminate the
> >> possible problems of interaction with `debug-on-error`).

> > The reason I suggested a signal call was so that the error information in
> > the successive ERRs would accumulate, rather than just being the fixed
> > ERR from the initial error.

I've been working out details in the last two or three days.  I actually
think the handler should exit with a (throw 'exit t).  That's because ...

> I think I agree tho "be in the innermost recursive `require'" seems
> quite vague.  But in any case the handlers of `handler-bind` are run
> before we unwind the stack (e.g. if your nesting looks like "require =>
> require => error" the two handlers of your two `require`s will be run
> before we get to the debugger but the debugger will still show the full
> stack.  Tho with your use of "resignaling" within the handlers, the
> stack will tend to be even "more full", with the two handlers nested
> and still active), so no matter how we do it, I think we will indeed get
> the behavior that I believe you describe.

We should respect any user setting of debug-on-error to anything non-nil.
If non-nil, we should enter the debugger within the handler-bind's
handler, so as to have access to Emacs's state when the error occurred.
This mechanism is used in eval-expression.  Also, this will prevent the
byte compiler having (eq byte-compile-debug nil) subverting the call of
the debugger.  After all, when loading a file, we're not actually in the
byte compiler, so byte-compile-debug shouldn't have an effect.

On leaving the debugger after an error, we definitely don't want to enter
the debugger again for the next file on the loading stack.  Hence we
should exit the handler with (throw 'exit t), or something like it.

[ .... ]

> In any case, it should be easy to try out and change from one to the
> other with very local changes (I'd expect that the code of the handlers
> will be written in ELisp rather than C, right?).  So either way is fine.

No, I think the handler code should be in C.  The function handler-bind-1
seems very clumsy for use from C code.  It requires a function with no
parameters, so this would likely involve creating a closure in the C
code.  This isn't good.

We should take inspiration from the functions internal_condition_case and
friends in eval.c, and create functions like internal_handler_bind.  This
would be almost identical to internal_condition_case, but would push a
HANDLER_BIND entry onto the handler stack rather than a CONDITION_CASE
one.  I think this would work well.

What do you say to all of this?  I'm about to start coding in earnest.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 02 Nov 2024 14:52:01 +0000
Resent-Message-ID: <handler.66912.B66912.173055911621905 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173055911621905
          (code B ref 66912); Sat, 02 Nov 2024 14:52:01 +0000
Received: (at 66912) by debbugs.gnu.org; 2 Nov 2024 14:51:56 +0000
Received: from localhost ([127.0.0.1]:53809 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t7FTo-0005hF-4m
	for submit <at> debbugs.gnu.org; Sat, 02 Nov 2024 10:51:56 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44289)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t7FTm-0005h5-6a
 for 66912 <at> debbugs.gnu.org; Sat, 02 Nov 2024 10:51:55 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 250C9802DA;
 Sat,  2 Nov 2024 10:51:48 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1730559107;
 bh=u+q32FUwbtSb9DuWpkg/yMsS9J7w51gkt2w0QrcijVA=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=BFox1karsslsIBZBlRvhT1r19EZ38i6ZHFsOCW1HfVCpNMKuYIRd/jFd9LUq83sNF
 VdOHj+NPArE4/kplsEhAcZ3lY5RxMbyDr7Ht3857n6sDbDaW1EH2SONolkxhb+nbV6
 lyH/kUREdNvE4OU0ycsUMXZhN0Be//so/Ewyfpc9RQEQG/gJjp1IMnQsbuGjsh3jfh
 9xosAGEZm+SeSZ/i8YlTcNXWaiHsfAycMxqikBS01xNrW+g5wUWd/t/vgEJ4dYWQrO
 qXhXIL/TI2iXZU/3h8yNSdLHZdafKQZ3CKBFhSgIm0kp6tr0t069JXnmNceediy3ca
 iEHhYASoAe0Pg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0F9278053B;
 Sat,  2 Nov 2024 10:51:47 -0400 (EDT)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E1E59120342;
 Sat,  2 Nov 2024 10:51:46 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZyYtYBLLKqas8r7B@HIDDEN> (Alan Mackenzie's message of
 "Sat, 2 Nov 2024 13:47:12 +0000")
Message-ID: <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
References: <ZUTaWfQQuGET2Fb2@ACM> <jwvv8aiq1vp.fsf-monnier+emacs@HIDDEN>
 <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
 <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
Date: Sat, 02 Nov 2024 10:51:46 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.002 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> I don't think we need either.  In lread.c, there is already a static
> variable Vloads_in_progress (which despite the name, is not visible in
> Lisp).  This variable is a stack of the file names currently being
> loaded.  We could surely just use this, and avoid code duplication.

In that case we don't need `handler-bind` at all, and we just tack the
info when we build the error object in `Fsignal`.

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".

With `handler-bind`s which add only the "current" file info, the error
will be labeled only with the relevant info, i.e. the intervening loads
between the `condition-case` (or `handler-bind`s) and the actual error.

> I've been working out details in the last two or three days.  I actually
> think the handler should exit with a (throw 'exit t).  That's because ...

What/where would be the matching `catch`?
I don't think the `handler-bind` we'd add to `load` should make
assumptions about how/where the errors will be handled.

>> I think I agree tho "be in the innermost recursive `require'" seems
>> quite vague.  But in any case the handlers of `handler-bind` are run
>> before we unwind the stack (e.g. if your nesting looks like "require =>
>> require => error" the two handlers of your two `require`s will be run
>> before we get to the debugger but the debugger will still show the full
>> stack.  Tho with your use of "resignaling" within the handlers, the
>> stack will tend to be even "more full", with the two handlers nested
>> and still active), so no matter how we do it, I think we will indeed get
>> the behavior that I believe you describe.
>
> We should respect any user setting of debug-on-error to anything non-nil.
> If non-nil, we should enter the debugger within the handler-bind's
> handler, so as to have access to Emacs's state when the error occurred.

I think we should do nothing special about `debug-on-error` and let it
be handled by the existing code: it should "just work".

> This mechanism is used in eval-expression.

That's because `eval-expression` doesn't want to obey `debug-on-error`.

> Also, this will prevent the byte compiler having (eq
> byte-compile-debug nil) subverting the call of the debugger.
> After all, when loading a file, we're not actually in the byte
> compiler, so byte-compile-debug shouldn't have an effect.

That would be nice.  Not sure how easy to do it, OTOH.

> On leaving the debugger after an error, we definitely don't want to
> enter the debugger again for the next file on the loading stack.
> Hence we should exit the handler with (throw 'exit t), or something
> like it.

If we're careful to preserve the `eq`ness of the error object, then the
debugger will know it has already been triggered for this error.

>> In any case, it should be easy to try out and change from one to the
>> other with very local changes (I'd expect that the code of the handlers
>> will be written in ELisp rather than C, right?).  So either way is fine.
> No, I think the handler code should be in C.  The function handler-bind-1
> seems very clumsy for use from C code.  It requires a function with no
> parameters, so this would likely involve creating a closure in the C
> code.  This isn't good.

I was talking about the code of the handlers.  I.e. the one we push
along with the HANDLER_BIND entry.   I'd build the handler by calling to
ELisp code (indeed, building closures from C is not good).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 03 Nov 2024 22:36:02 +0000
Resent-Message-ID: <handler.66912.B66912.173067331231853 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173067331231853
          (code B ref 66912); Sun, 03 Nov 2024 22:36:02 +0000
Received: (at 66912) by debbugs.gnu.org; 3 Nov 2024 22:35:12 +0000
Received: from localhost ([127.0.0.1]:35322 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t7jBe-0008Hf-Pg
	for submit <at> debbugs.gnu.org; Sun, 03 Nov 2024 17:35:12 -0500
Received: from mail.muc.de ([193.149.48.3]:56666)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t7jBb-0008BU-PJ
 for 66912 <at> debbugs.gnu.org; Sun, 03 Nov 2024 17:35:09 -0500
Received: (qmail 49803 invoked by uid 3782); 3 Nov 2024 23:35:00 +0100
Received: from muc.de (pd953a0dd.dip0.t-ipconnect.de [217.83.160.221]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Sun, 03 Nov 2024 23:34:59 +0100
Received: (qmail 24972 invoked by uid 1000); 3 Nov 2024 22:34:58 -0000
Date: Sun, 3 Nov 2024 22:34:58 +0000
Message-ID: <Zyf6ki4nk8titM2D@HIDDEN>
References: <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
 <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

I have a first version of a patch for this.  Please see below.

On Sat, Nov 02, 2024 at 10:51:46 -0400, Stefan Monnier wrote:
> > I don't think we need either.  In lread.c, there is already a static
> > variable Vloads_in_progress (which despite the name, is not visible in
> > Lisp).  This variable is a stack of the file names currently being
> > loaded.  We could surely just use this, and avoid code duplication.

> In that case we don't need `handler-bind` at all, and we just tack the
> info when we build the error object in `Fsignal`.

I've actually made a copy of Vloads_in_progress to
Vloads_still_in_progress, a variable which isn't bound, hence whose
binding won't get lost in an error situation.  I'm not convinced we need
both of these, though.

> 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".

Currently, my messages are "While loading foo.el... While loading
bar.el... While loading baz.el...\n<error message>.

[ .... ]

> > I've been working out details in the last two or three days.  I actually
> > think the handler should exit with a (throw 'exit t).  That's because ...

> What/where would be the matching `catch`?

I actually put in a (throw 'top-level t) on exit from the debugger.

> I don't think the `handler-bind` we'd add to `load` should make
> assumptions about how/where the errors will be handled.

The handler-bind handler I've added calls the debugger if debug-on-error
is non-nil.  Otherwise it just exits, letting something else handle the
error.

[ .... ]

> > We should respect any user setting of debug-on-error to anything
> > non-nil.  If non-nil, we should enter the debugger within the
> > handler-bind's handler, so as to have access to Emacs's state when
> > the error occurred.

> I think we should do nothing special about `debug-on-error` and let it
> be handled by the existing code: it should "just work".

Well, I've done something special with it, as I proposed.  

[ .... ]

> > Also, this will prevent the byte compiler having (eq
> > byte-compile-debug nil) subverting the call of the debugger.
> > After all, when loading a file, we're not actually in the byte
> > compiler, so byte-compile-debug shouldn't have an effect.

> That would be nice.  Not sure how easy to do it, OTOH.

It's done.  :-)  Please see my patch.

[ .... ]

> >> In any case, it should be easy to try out and change from one to the
> >> other with very local changes (I'd expect that the code of the handlers
> >> will be written in ELisp rather than C, right?).  So either way is fine.
> > No, I think the handler code should be in C.  The function handler-bind-1
> > seems very clumsy for use from C code.  It requires a function with no
> > parameters, so this would likely involve creating a closure in the C
> > code.  This isn't good.

> I was talking about the code of the handlers.  I.e. the one we push
> along with the HANDLER_BIND entry.   I'd build the handler by calling to
> ELisp code (indeed, building closures from C is not good).

I've extended the handler-bind mechanism to enable handlers to be
written in C.  They have the advantage that there is no minimum amount
of Lisp which needs to be loaded before the error handler can report a
problem with nested requires.

Anyhow, here's the patch (first version).  Please let me know what you
think.  Thanks!



diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index f058fc48cc7..776083468c6 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -1436,8 +1436,9 @@ byte-compile-report-error
 when printing the error message."
   (setq byte-compiler-error-flag t)
   (byte-compile-log-warning
-   (if (stringp error-info) error-info
-     (error-message-string error-info))
+   (prefix-load-file-names
+    (if (stringp error-info) error-info
+      (error-message-string error-info)))
    fill :error))
 
 ;;; sanity-checking arglists
diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index ec947c1215d..d49ebb20fd8 100644
--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -426,8 +426,10 @@ debugger--insert-header
     ;; User calls debug directly.
     (_
      (insert ": ")
-     (insert (backtrace-print-to-string (if (eq (car args) 'nil)
-                                            (cdr args) args)))
+     (insert
+      (prefix-load-file-names
+       (backtrace-print-to-string (if (eq (car args) 'nil)
+                                      (cdr args) args))))
      (insert ?\n))))
 
 
diff --git a/src/eval.c b/src/eval.c
index d0a2abf0089..8f95bd4d263 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1581,20 +1581,77 @@ internal_lisp_condition_case (Lisp_Object var, Lisp_Object bodyform,
 }
 
 /* Call the function BFUN with no arguments, catching errors within it
-   according to HANDLERS.  If there is an error, call HFUN with
-   one argument which is the data that describes the error:
+   according to HANDLERTYPE and HANDLERS.  If there is an error, call
+   HFUN with one argument which is the data that describes the error:
    (SIGNALNAME . DATA)
 
+   HANDLERTYPE must be either CONDITION_CASE or HANDLER_BIND.
+
    HANDLERS can be a list of conditions to catch.
    If HANDLERS is Qt, catch all errors.
    If HANDLERS is Qerror, catch all errors
    but allow the debugger to run if that is enabled.  */
 
+static Lisp_Object
+internal_cc_hb (enum handlertype handlertype,
+		Lisp_Object (*bfun) (void), Lisp_Object handlers,
+		Lisp_Object (*hfun) (Lisp_Object))
+{
+  struct handler *c = push_handler (handlers, handlertype);
+
+  if (handlertype == HANDLER_BIND)
+    {
+      c->val = Qnil;
+      c->bin_handler = hfun;
+      c->bytecode_dest = 0;
+    }
+  if (sys_setjmp (c->jmp))
+    {
+      Lisp_Object val = handlerlist->val;
+      clobbered_eassert (handlerlist == c);
+      handlerlist = handlerlist->next;
+      return hfun (val);
+    }
+  else
+    {
+      Lisp_Object val = bfun ();
+      eassert (handlerlist == c);
+      handlerlist = c->next;
+      return val;
+    }
+}
+
 Lisp_Object
 internal_condition_case (Lisp_Object (*bfun) (void), Lisp_Object handlers,
 			 Lisp_Object (*hfun) (Lisp_Object))
 {
-  struct handler *c = push_handler (handlers, CONDITION_CASE);
+  return internal_cc_hb (CONDITION_CASE, bfun, handlers, hfun);
+}
+
+Lisp_Object
+internal_handler_bind (Lisp_Object (*bfun) (void), Lisp_Object handlers,
+		       Lisp_Object (*hfun) (Lisp_Object))
+{
+  if (NILP (Flistp (handlers)))
+    handlers = Fcons (handlers, Qnil);
+  return internal_cc_hb (HANDLER_BIND, bfun, handlers, hfun);
+}
+
+/* Like internal_cc_hb but call BFUN with ARG as its argument.  */
+
+static Lisp_Object
+internal_cc_hb_1 (enum handlertype handlertype,
+		  Lisp_Object (*bfun) (Lisp_Object), Lisp_Object arg,
+		  Lisp_Object handlers,
+		  Lisp_Object (*hfun) (Lisp_Object))
+{
+  struct handler *c = push_handler (handlers, handlertype);
+  if (handlertype == HANDLER_BIND)
+    {
+      c->val = Qnil;
+      c->bin_handler = hfun;
+      c->bytecode_dest = 0;
+    }
   if (sys_setjmp (c->jmp))
     {
       Lisp_Object val = handlerlist->val;
@@ -1604,21 +1661,49 @@ internal_condition_case (Lisp_Object (*bfun) (void), Lisp_Object handlers,
     }
   else
     {
-      Lisp_Object val = bfun ();
+      Lisp_Object val = bfun (arg);
       eassert (handlerlist == c);
       handlerlist = c->next;
       return val;
     }
 }
 
-/* Like internal_condition_case but call BFUN with ARG as its argument.  */
-
 Lisp_Object
 internal_condition_case_1 (Lisp_Object (*bfun) (Lisp_Object), Lisp_Object arg,
 			   Lisp_Object handlers,
 			   Lisp_Object (*hfun) (Lisp_Object))
 {
-  struct handler *c = push_handler (handlers, CONDITION_CASE);
+  return internal_cc_hb_1 (CONDITION_CASE, bfun, arg, handlers, hfun);
+}
+
+Lisp_Object
+internal_handler_bind_1 (Lisp_Object (*bfun) (Lisp_Object), Lisp_Object arg,
+			 Lisp_Object handlers,
+			 Lisp_Object (*hfun) (Lisp_Object))
+{
+  if (NILP (Flistp (handlers)))
+    handlers = Fcons (handlers, Qnil);
+  return internal_cc_hb_1 (HANDLER_BIND, bfun, arg, handlers, hfun);
+}
+
+/* Like internal_cc_hb_1 but call BFUN with ARG1 and ARG2 as
+   its arguments.  */
+
+static Lisp_Object
+internal_cc_hb_2 (enum handlertype handlertype,
+		  Lisp_Object (*bfun) (Lisp_Object, Lisp_Object),
+		  Lisp_Object arg1,
+		  Lisp_Object arg2,
+		  Lisp_Object handlers,
+		  Lisp_Object (*hfun) (Lisp_Object))
+{
+  struct handler *c = push_handler (handlers, handlertype);
+  if (handlertype == HANDLER_BIND)
+    {
+      c->val = Qnil;
+      c->bin_handler = hfun;
+      c->bytecode_dest = 0;
+    }
   if (sys_setjmp (c->jmp))
     {
       Lisp_Object val = handlerlist->val;
@@ -1628,16 +1713,13 @@ internal_condition_case_1 (Lisp_Object (*bfun) (Lisp_Object), Lisp_Object arg,
     }
   else
     {
-      Lisp_Object val = bfun (arg);
+      Lisp_Object val = bfun (arg1, arg2);
       eassert (handlerlist == c);
       handlerlist = c->next;
       return val;
     }
 }
 
-/* Like internal_condition_case_1 but call BFUN with ARG1 and ARG2 as
-   its arguments.  */
-
 Lisp_Object
 internal_condition_case_2 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object),
 			   Lisp_Object arg1,
@@ -1645,7 +1727,38 @@ internal_condition_case_2 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object),
 			   Lisp_Object handlers,
 			   Lisp_Object (*hfun) (Lisp_Object))
 {
-  struct handler *c = push_handler (handlers, CONDITION_CASE);
+  return internal_cc_hb_2 (CONDITION_CASE, bfun, arg1, arg2, handlers, hfun);
+}
+
+Lisp_Object
+internal_handler_bind_2 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object),
+			 Lisp_Object arg1,
+			 Lisp_Object arg2,
+			 Lisp_Object handlers,
+			 Lisp_Object (*hfun) (Lisp_Object))
+{
+  if (NILP (Flistp (handlers)))
+    handlers = Fcons (handlers, Qnil);
+  return internal_cc_hb_2 (HANDLER_BIND, bfun, arg1, arg2, handlers, hfun);
+}
+
+/* Like internal_cc_hb_2 but the second argument is an arbitrary pointer.  */
+
+static Lisp_Object
+internal_cc_hb_1_voidstar (enum handlertype handlertype,
+			   Lisp_Object (*bfun) (Lisp_Object, void *),
+			   Lisp_Object arg1,
+			   void *arg2,
+			   Lisp_Object handlers,
+			   Lisp_Object (*hfun) (Lisp_Object))
+{
+  struct handler *c = push_handler (handlers, handlertype);
+  if (handlertype == HANDLER_BIND)
+    {
+      c->val = Qnil;
+      c->bin_handler = hfun;
+      c->bytecode_dest = 0;
+    }
   if (sys_setjmp (c->jmp))
     {
       Lisp_Object val = handlerlist->val;
@@ -1662,6 +1775,30 @@ internal_condition_case_2 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object),
     }
 }
 
+Lisp_Object
+internal_condition_case_1_voidstar (Lisp_Object (*bfun) (Lisp_Object, void *),
+				    Lisp_Object arg1,
+				    void *arg2,
+				    Lisp_Object handlers,
+				    Lisp_Object (*hfun) (Lisp_Object))
+{
+  return internal_cc_hb_1_voidstar (CONDITION_CASE, bfun, arg1, arg2,
+				     handlers, hfun);
+}
+
+Lisp_Object
+internal_handler_bind_1_voidstar (Lisp_Object (*bfun) (Lisp_Object, void *),
+			 Lisp_Object arg1,
+			 void *arg2,
+			 Lisp_Object handlers,
+			 Lisp_Object (*hfun) (Lisp_Object))
+{
+  if (NILP (Flistp (handlers)))
+    handlers = Fcons (handlers, Qnil);
+  return internal_cc_hb_1_voidstar (HANDLER_BIND, bfun, arg1, arg2,
+				    handlers, hfun);
+}
+
 /* Like internal_condition_case but call BFUN with NARGS as first,
    and ARGS as second argument.  */
 
@@ -1691,6 +1828,35 @@ internal_condition_case_n (Lisp_Object (*bfun) (ptrdiff_t, Lisp_Object *),
     }
 }
 
+Lisp_Object
+internal_handler_bind_n (Lisp_Object (*bfun) (ptrdiff_t, Lisp_Object *),
+			 ptrdiff_t nargs,
+			 Lisp_Object *args,
+			 Lisp_Object handlers,
+			 Lisp_Object (*hfun) (Lisp_Object err))
+{
+  struct handler *c = push_handler (handlers, HANDLER_BIND);
+    {
+      c->val = Qnil;
+      c->bin_handler = hfun;
+      c->bytecode_dest = 0;
+    }
+  if (sys_setjmp (c->jmp))
+    {
+      Lisp_Object val = handlerlist->val;
+      clobbered_eassert (handlerlist == c);
+      handlerlist = handlerlist->next;
+      return hfun (val);
+    }
+  else
+    {
+      Lisp_Object val = bfun (nargs, args);
+      eassert (handlerlist == c);
+      handlerlist = c->next;
+      return val;
+    }
+}
+
 static Lisp_Object Qcatch_all_memory_full;
 
 /* Like a combination of internal_condition_case_1 and internal_catch.
@@ -1900,9 +2066,12 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool continuable)
 	        max_ensure_room (20);
 	        push_handler (make_fixnum (skip + h->bytecode_dest),
 	                      SKIP_CONDITIONS);
-	        call1 (h->val, error);
-	        unbind_to (count, Qnil);
-	        pop_handler ();
+		if (NILP (h->val))
+		  (h->bin_handler) (error);
+		else
+		  call1 (h->val, error);
+	        unbind_to (count, Qnil); /* Removes SKIP_CONDITIONS handler.  */
+	        pop_handler ();		 /* Discards HANDLER_BIND handler.  */
 	      }
 	    continue;
 	  }
diff --git a/src/keyboard.c b/src/keyboard.c
index 6d28dca9aeb..6758c328038 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -1096,7 +1096,7 @@ DEFUN ("command-error-default-function", Fcommand_error_default_function,
 	  Fdiscard_input ();
 	  bitch_at_user ();
 	}
-
+      context = Fprefix_load_file_names (context);
       print_error_message (data, Qt, SSDATA (context), signal);
     }
   return Qnil;
diff --git a/src/lisp.h b/src/lisp.h
index 5ef97047f76..205a5aa747b 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -3870,7 +3870,9 @@ record_in_backtrace (Lisp_Object function, Lisp_Object *args, ptrdiff_t nargs)
                                    'val' holds the retval during longjmp.  */
   HANDLER_BIND,                 /* Entry for 'handler-bind'.
                                    'tag_or_ch' holds the list of conditions.
-                                   'val' holds the handler function.
+                                   `val', if non-nil, holds the Lisp handler
+                                   function.  If nil, the handler function
+                                   is a C function held in `bin_handler'.
                                    The rest of the handler is unused,
                                    except for 'bytecode_dest' that holds
                                    the number of preceding HANDLER_BIND
@@ -3920,6 +3922,7 @@ record_in_backtrace (Lisp_Object function, Lisp_Object *args, ptrdiff_t nargs)
   struct bc_frame *act_rec;
   int poll_suppress_count;
   int interrupt_input_blocked;
+  Lisp_Object (*bin_handler) (Lisp_Object); /* Used only for HANDLER_BIND. */
 
 #ifdef HAVE_X_WINDOWS
   int x_error_handler_depth;
@@ -4873,11 +4876,19 @@ xsignal (Lisp_Object error_symbol, Lisp_Object data)
 extern Lisp_Object internal_catch (Lisp_Object, Lisp_Object (*) (Lisp_Object), Lisp_Object);
 extern Lisp_Object internal_lisp_condition_case (Lisp_Object, Lisp_Object, Lisp_Object);
 extern Lisp_Object internal_condition_case (Lisp_Object (*) (void), Lisp_Object, Lisp_Object (*) (Lisp_Object));
+extern Lisp_Object internal_handler_bind (Lisp_Object (*) (void), Lisp_Object, Lisp_Object (*) (Lisp_Object));
 extern Lisp_Object internal_condition_case_1 (Lisp_Object (*) (Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
+extern Lisp_Object internal_handler_bind_1 (Lisp_Object (*) (Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
 extern Lisp_Object internal_condition_case_2 (Lisp_Object (*) (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
+extern Lisp_Object internal_handler_bind_2 (Lisp_Object (*) (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
+extern Lisp_Object internal_condition_case_1_voidstar (Lisp_Object (*) (Lisp_Object, void*), Lisp_Object, void *, Lisp_Object, Lisp_Object (*) (Lisp_Object));
+extern Lisp_Object internal_handler_bind_1_voidstar (Lisp_Object (*) (Lisp_Object, void *), Lisp_Object, void *, Lisp_Object, Lisp_Object (*) (Lisp_Object));
 extern Lisp_Object internal_condition_case_n
     (Lisp_Object (*) (ptrdiff_t, Lisp_Object *), ptrdiff_t, Lisp_Object *,
      Lisp_Object, Lisp_Object (*) (Lisp_Object, ptrdiff_t, Lisp_Object *));
+extern Lisp_Object internal_handler_bind_n
+    (Lisp_Object (*) (ptrdiff_t, Lisp_Object *), ptrdiff_t, Lisp_Object *,
+     Lisp_Object, Lisp_Object (*) (Lisp_Object));
 extern Lisp_Object internal_catch_all (Lisp_Object (*) (void *), void *, Lisp_Object (*) (enum nonlocal_exit, Lisp_Object));
 extern struct handler *push_handler (Lisp_Object, enum handlertype)
   ATTRIBUTE_RETURNS_NONNULL;
diff --git a/src/lread.c b/src/lread.c
index ea0398196e3..2fb407d9948 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -234,8 +234,10 @@ #define USE_ANDROID_ASSETS
 
 /* A list of file names for files being loaded in Fload.  Used to
    check for recursive loads.  */
-
 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;
 
 static int read_emacs_mule_char (int, int (*) (int, Lisp_Object),
                                  Lisp_Object);
@@ -1271,6 +1273,51 @@ close_file_unwind_android_fd (void *ptr)
 
 #endif
 
+/* Call readevalloop inside a `handler-bind' form.  */
+static Lisp_Object
+load_readevalloop (Lisp_Object hist_file_name, struct infile *input)
+{
+  readevalloop (Qget_file_char, input, hist_file_name,
+		0, Qnil, Qnil, Qnil, Qnil);
+  return Qnil;
+}
+
+DEFUN ("prefix-load-file-names", Fprefix_load_file_names,
+       Sprefix_load_file_names, 1, 1, 0,
+       doc: /* Prefix the string BASE_STRING with a message about each
+file currently being loaded.  Return the resulting string and reset this
+information to null.  */)
+  (Lisp_Object base_string)
+{
+  Lisp_Object result = build_string ("");
+  Lisp_Object while_loading = build_string ("While loading ");
+  Lisp_Object ellipsis = build_string ("... ");
+
+  while (!NILP (Vloads_still_in_progress))
+    {
+      result = concat2 (concat3 (while_loading,
+				 Fcar (Vloads_still_in_progress),
+				 ellipsis),
+			result);
+      Vloads_still_in_progress = Fcdr (Vloads_still_in_progress);
+    }
+  result = concat3 (result, build_string ("\n"), base_string);
+  return result;
+}
+
+/* Handle errors signalled by the above function.  */
+static Lisp_Object
+rel_error_handler (Lisp_Object err)
+{
+  if (!NILP (Vdebug_on_error))
+    {
+      call_debugger (err);
+      Fthrow (Qtop_level, Qt);
+    }
+  else
+    return err;
+}
+
 DEFUN ("load", Fload, Sload, 1, 5, 0,
        doc: /* Execute a file of Lisp code named FILE.
 First try FILE with `.elc' appended, then try with `.el', then try
@@ -1516,6 +1563,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
 	signal_error ("Recursive load", Fcons (found, Vloads_in_progress));
     record_unwind_protect (record_load_unwind, Vloads_in_progress);
     Vloads_in_progress = Fcons (found, Vloads_in_progress);
+    Vloads_still_in_progress = Vloads_in_progress;
   }
 
   /* All loads are by default dynamic, unless the file itself specifies
@@ -1606,16 +1654,25 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
       if (!NILP (Vload_source_file_function))
 	{
 	  Lisp_Object val;
+	  Lisp_Object args[5];
 
 	  if (lread_fd_p)
 	    {
 	      lread_close (fd);
 	      clear_unwind_protect (fd_index);
 	    }
-	  val = call4 (Vload_source_file_function, found, hist_file_name,
-		       NILP (noerror) ? Qnil : Qt,
-		       (NILP (nomessage) || force_load_messages) ? Qnil : Qt);
-	  return unbind_to (count, val);
+	  args[0] = Vload_source_file_function;
+	  args[1] = found;
+	  args[2] = hist_file_name;
+	  args[3] = NILP (noerror) ? Qnil : Qt;
+	  args[4] = (NILP (nomessage) || force_load_messages) ? Qnil : Qt;
+	  val = internal_handler_bind_n (Ffuncall,
+					 5, args,
+					 Qerror,
+					 rel_error_handler);
+	  unbind_to (count, Qnil);
+	  Vloads_still_in_progress = Vloads_in_progress;
+	  return val;
 	}
     }
 
@@ -1724,8 +1781,11 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
         Fset (Qlexical_binding, Qt);
 
       if (! version || version >= 22)
-        readevalloop (Qget_file_char, &input, hist_file_name,
-                      0, Qnil, Qnil, Qnil, Qnil);
+	internal_handler_bind_1_voidstar
+	  ((Lisp_Object (*) (Lisp_Object, void *)) load_readevalloop,
+	   hist_file_name,
+	   &input,
+	   Qerror, rel_error_handler);
       else
         {
           /* We can't handle a file which was compiled with
@@ -1741,6 +1801,8 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
   if (!NILP (Ffboundp (Qdo_after_load_evaluation)))
     call1 (Qdo_after_load_evaluation, hist_file_name) ;
 
+  Vloads_still_in_progress = Vloads_in_progress;
+
   for (int i = 0; i < ARRAYELTS (saved_strings); i++)
     {
       xfree (saved_strings[i].string);
@@ -5772,6 +5834,7 @@ init_lread (void)
   Vload_true_file_name = Qnil;
   Vstandard_input = Qt;
   Vloads_in_progress = Qnil;
+  Vloads_still_in_progress = Qnil;
 }
 
 /* Print a warning that directory intended for use USE and with name
@@ -5819,6 +5882,7 @@ syms_of_lread (void)
   defsubr (&Sintern_soft);
   defsubr (&Sunintern);
   defsubr (&Sget_load_suffixes);
+  defsubr (&Sprefix_load_file_names);
   defsubr (&Sload);
   defsubr (&Seval_buffer);
   defsubr (&Seval_region);
@@ -6138,6 +6202,8 @@ syms_of_lread (void)
 
   Vloads_in_progress = Qnil;
   staticpro (&Vloads_in_progress);
+  Vloads_still_in_progress = Qnil;
+  staticpro (&Vloads_still_in_progress);
 
   DEFSYM (Qhash_table, "hash-table");
   DEFSYM (Qdata, "data");


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 04 Nov 2024 02:47:02 +0000
Resent-Message-ID: <handler.66912.B66912.173068841330386 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173068841330386
          (code B ref 66912); Mon, 04 Nov 2024 02:47:02 +0000
Received: (at 66912) by debbugs.gnu.org; 4 Nov 2024 02:46:53 +0000
Received: from localhost ([127.0.0.1]:36631 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t7n7F-0007u2-6B
	for submit <at> debbugs.gnu.org; Sun, 03 Nov 2024 21:46:53 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20758)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t7n7C-0007tu-ON
 for 66912 <at> debbugs.gnu.org; Sun, 03 Nov 2024 21:46:52 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0E1261000C3;
 Sun,  3 Nov 2024 21:46:44 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1730688403;
 bh=iAjVAwampBRv3kXPrCGVov6pVGLJ6uZmTV/mkU91VX0=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=PYywALgQKAmMtpuOGLpvu7aTPtO8vUBO43pcIhDul/Fm5wYBvW48MHi/xlLtAZAL1
 9mtugGNmgCohw04G73J6pCo9gA7i84UqkM8bNGBhU5rnDbf1CUGPoj99kB5gH3EVdv
 dDqUrWFc9RcEbvNFWUU1D1oxtF8f8rDCAhW05nHD6ze/claYMNFN9hK64/SGfKeern
 FOf5lp9/1htQmJ23pNY5uT4LEE3NNko3Lgn2twxuiKIjKnCfG6qddMPJaVFQ517Ify
 3L0DdFJmEMgJJyz1S7q34d1L9J4NrtT/hMG6J8Mn9Sw9IjDpHBU0isUrfTPYYrjpS6
 gjTHvaPkbGWFg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 355EC100042;
 Sun,  3 Nov 2024 21:46:43 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0D50F12038B;
 Sun,  3 Nov 2024 21:46:43 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <Zyf6ki4nk8titM2D@HIDDEN> (Alan Mackenzie's message of
 "Sun, 3 Nov 2024 22:34:58 +0000")
Message-ID: <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
References: <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
 <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
Date: Sun, 03 Nov 2024 21:46:42 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.096 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Hi Alan,

I couldn't properly review your code because I had trouble
understanding it.  So instead, it's mostly questions.

> +static Lisp_Object
> +internal_cc_hb (enum handlertype handlertype,
> +		Lisp_Object (*bfun) (void), Lisp_Object handlers,
> +		Lisp_Object (*hfun) (Lisp_Object))
> +{
> +  struct handler *c = push_handler (handlers, handlertype);
> +
> +  if (handlertype == HANDLER_BIND)
> +    {
> +      c->val = Qnil;
> +      c->bin_handler = hfun;
> +      c->bytecode_dest = 0;
> +    }
> +  if (sys_setjmp (c->jmp))
> +    {
> +      Lisp_Object val = handlerlist->val;
> +      clobbered_eassert (handlerlist == c);
> +      handlerlist = handlerlist->next;
> +      return hfun (val);
> +    }
> +  else
> +    {
> +      Lisp_Object val = bfun ();
> +      eassert (handlerlist == c);
> +      handlerlist = c->next;
> +      return val;
> +    }
> +}

I don't understand the above code: `handler-bind` is not supposed to
call setjmp/longjmp: when the handler of a `handler-bind` gets called,
the stack is not unwound.
So what is the `sys_setjmp` for when `handlertype == HANDLER_BIND`?

> @@ -1900,9 +2066,12 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool continuable)
>  	        max_ensure_room (20);
>  	        push_handler (make_fixnum (skip + h->bytecode_dest),
>  	                      SKIP_CONDITIONS);
> -	        call1 (h->val, error);
> -	        unbind_to (count, Qnil);
> -	        pop_handler ();
> +		if (NILP (h->val))
> +		  (h->bin_handler) (error);

[ We don't need parens around `h->bin_handler`.  ]

> +		else
> +		  call1 (h->val, error);
> +	        unbind_to (count, Qnil); /* Removes SKIP_CONDITIONS handler.  */
> +	        pop_handler ();		 /* Discards HANDLER_BIND handler.  */

These comments don't match my understanding of the code: IIRC the
`pop_handler` pops the `SKIP_CONDITIONS` handler.  Also there's no
reason to presume the HANDLER_BIND handler is at the top, so if we
wanted to remove it, we'd have to work harder.

> +/* Handle errors signalled by the above function.  */
> +static Lisp_Object
> +rel_error_handler (Lisp_Object err)
> +{
> +  if (!NILP (Vdebug_on_error))
> +    {
> +      call_debugger (err);
> +      Fthrow (Qtop_level, Qt);
> +    }
> +  else
> +    return err;
> +}

I don't understand that.
AFAICT, this is the only HANDLER_BIND handler you install from
C code, right?  So this is the thing that motivates all the changes like
`internal_cc_hb`, etc... so clearly it must do something worthwhile, but
I don't see what it is.
How is this related to `Fprefix_load_file_names`?


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 04 Nov 2024 12:21:02 +0000
Resent-Message-ID: <handler.66912.B66912.17307228192365 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: monnier@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17307228192365
          (code B ref 66912); Mon, 04 Nov 2024 12:21:02 +0000
Received: (at 66912) by debbugs.gnu.org; 4 Nov 2024 12:20:19 +0000
Received: from localhost ([127.0.0.1]:39506 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t7w4A-0000c4-Ly
	for submit <at> debbugs.gnu.org; Mon, 04 Nov 2024 07:20:18 -0500
Received: from eggs.gnu.org ([209.51.188.92]:39088)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1t7w48-0000bk-Ag
 for 66912 <at> debbugs.gnu.org; Mon, 04 Nov 2024 07:20:17 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1t7w41-0007gg-8w; Mon, 04 Nov 2024 07:20:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=mUc7VnSWZV75/TdGrXiGzOQpfF8t/Gwyj79ENYV86aU=; b=gqFvHWXFFEI8
 P5iqZ+gGDtTS16hj/tEFHGLS9Lpswk1XGTJZ4i3LLyIfgu/WfXZr6CO5PmjuixRRgrw07wtekPlRs
 gwxaocqnpUw6jyY7tUeHWH9D3nI53dohGuhoT2vOP3rx9Soa3dEKOMMgOQ5RcSem5y0/Sld/JXiDU
 gh2yG16ouOwXfwzgon16Ctxf55/UdhHtN1jTrsBMlH4OWx5vVGkwbNbcFa5iO3mTLpxohyGLkzqwb
 4v4V9Yt9WFIlrUPAnLkygfE3+XXTpMXH2yvilPibJUAkp8auW+EhaW8SeMKu6kBVXuMyyi1cxkfrN
 zO42DyUP+iOo3CKRlU/SkQ==;
Date: Mon, 04 Nov 2024 14:20:06 +0200
Message-Id: <864j4nw5qh.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <Zyf6ki4nk8titM2D@HIDDEN> (message from Alan Mackenzie on
 Sun, 3 Nov 2024 22:34:58 +0000)
References: <ZVD9jhW_i23vbPTe@ACM> <jwv8r72vqsq.fsf-monnier+emacs@HIDDEN>
 <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN> <Zyf6ki4nk8titM2D@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
> Date: Sun, 3 Nov 2024 22:34:58 +0000
> From: Alan Mackenzie <acm@HIDDEN>
> 
> +static Lisp_Object
> +internal_cc_hb (enum handlertype handlertype,

Please don't use such cryptic names for functions.  There's no need to
keep function names short if that runs afoul of mnemonics.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 04 Nov 2024 12:53:02 +0000
Resent-Message-ID: <handler.66912.B66912.17307247426362 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17307247426362
          (code B ref 66912); Mon, 04 Nov 2024 12:53:02 +0000
Received: (at 66912) by debbugs.gnu.org; 4 Nov 2024 12:52:22 +0000
Received: from localhost ([127.0.0.1]:39670 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t7wZB-0001eY-Mo
	for submit <at> debbugs.gnu.org; Mon, 04 Nov 2024 07:52:22 -0500
Received: from mail.muc.de ([193.149.48.3]:41047)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t7wZ8-0001eM-MS
 for 66912 <at> debbugs.gnu.org; Mon, 04 Nov 2024 07:52:20 -0500
Received: (qmail 54737 invoked by uid 3782); 4 Nov 2024 13:52:11 +0100
Received: from muc.de (p4fe1531c.dip0.t-ipconnect.de [79.225.83.28]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 04 Nov 2024 13:52:11 +0100
Received: (qmail 5705 invoked by uid 1000); 4 Nov 2024 12:52:10 -0000
Date: Mon, 4 Nov 2024 12:52:10 +0000
Message-ID: <ZyjDerzdpdMJwO5d@HIDDEN>
References: <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

Thanks for such a rapid response!

On Sun, Nov 03, 2024 at 21:46:42 -0500, Stefan Monnier wrote:
> Hi Alan,

> I couldn't properly review your code because I had trouble
> understanding it.  So instead, it's mostly questions.

> > +static Lisp_Object
> > +internal_cc_hb (enum handlertype handlertype,
> > +		Lisp_Object (*bfun) (void), Lisp_Object handlers,
> > +		Lisp_Object (*hfun) (Lisp_Object))
> > +{
> > +  struct handler *c = push_handler (handlers, handlertype);
> > +
> > +  if (handlertype == HANDLER_BIND)
> > +    {
> > +      c->val = Qnil;
> > +      c->bin_handler = hfun;
> > +      c->bytecode_dest = 0;
> > +    }
> > +  if (sys_setjmp (c->jmp))
> > +    {
> > +      Lisp_Object val = handlerlist->val;
> > +      clobbered_eassert (handlerlist == c);
> > +      handlerlist = handlerlist->next;
> > +      return hfun (val);
> > +    }
> > +  else
> > +    {
> > +      Lisp_Object val = bfun ();
> > +      eassert (handlerlist == c);
> > +      handlerlist = c->next;
> > +      return val;
> > +    }
> > +}

> I don't understand the above code: `handler-bind` is not supposed to
> call setjmp/longjmp: when the handler of a `handler-bind` gets called,
> the stack is not unwound.

I started off by just making the HANDLER_BIND case use the same code as
CONDITION_CASE, and got segfaults.  I've tried to find the places where
a longjmp gets called for condition-case, but my brain's tired after a
weekend of heavy coding.

Given HANDLER_BIND doesn't need the setjmp/longjmp mechanism, it would
seem there's no sense in combining the HANDLER_BIND and CONDITION_CASE
cases in internal_cc_hb and friends.  I should just restore the
condition-case functions to what they were, and add separate new ones
for handler-bind.

> So what is the `sys_setjmp` for when `handlertype == HANDLER_BIND`?

After reading your previous paragraph, probably nothing.

[ .... ]

> [ We don't need parens around `h->bin_handler`.  ]

They've gone.

> > +		else
> > +		  call1 (h->val, error);
> > +	        unbind_to (count, Qnil); /* Removes SKIP_CONDITIONS handler.  */
> > +	        pop_handler ();		 /* Discards HANDLER_BIND handler.  */

> These comments don't match my understanding of the code: IIRC the
> `pop_handler` pops the `SKIP_CONDITIONS` handler.

I think I see now you're right.  push_handler doesn't push an entry onto
the binding stack.  I'll amend these comments as soon as I understand
the code.  I think these lines definitely need comments.

> Also there's no reason to presume the HANDLER_BIND handler is at the
> top, so if we wanted to remove it, we'd have to work harder.

This code is difficult to understand.  What is the purpose of the
binding block around the call of the handler function?  I think a
comment here would help.

> > +/* Handle errors signalled by the above function.  */
> > +static Lisp_Object
> > +rel_error_handler (Lisp_Object err)
> > +{
> > +  if (!NILP (Vdebug_on_error))
> > +    {
> > +      call_debugger (err);
> > +      Fthrow (Qtop_level, Qt);
> > +    }
> > +  else
> > +    return err;
> > +}

> I don't understand that.
> AFAICT, this is the only HANDLER_BIND handler you install from
> C code, right?  So this is the thing that motivates all the changes like
> `internal_cc_hb`, etc... so clearly it must do something worthwhile, but
> I don't see what it is.

rel_error_handler is currently the only such handler, yes.  All this
code (once it's debugged) will fix the inconsistency that
condition-case, unwind-protect, catch and throw, ... can all be used
from C code, but handler-bind can't be.

rel_error_handler, in particular, allows the debugger to be called
regardless of any active condition_cases which would otherwise block it.
In the byte compiler, there is such a blocking condition-case set up by
bytecomp--displaying-warnings when byte-compile-debug is nil.  This
mechanism is currently only used in Fload.

> How is this related to `Fprefix_load_file_names`?

Not closely.  I think I should have propsed two separate patches, rather
than the big one I did.  Fprefix_load_file_names is what puts the "While
loading foo.el... " in front of an error message.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 04 Nov 2024 13:14:02 +0000
Resent-Message-ID: <handler.66912.B66912.17307260039067 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: acm@HIDDEN, monnier@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17307260039067
          (code B ref 66912); Mon, 04 Nov 2024 13:14:02 +0000
Received: (at 66912) by debbugs.gnu.org; 4 Nov 2024 13:13:23 +0000
Received: from localhost ([127.0.0.1]:39834 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t7wtW-0002MB-Lm
	for submit <at> debbugs.gnu.org; Mon, 04 Nov 2024 08:13:22 -0500
Received: from mail.muc.de ([193.149.48.3]:37858)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t7wtU-0002M3-9P
 for 66912 <at> debbugs.gnu.org; Mon, 04 Nov 2024 08:13:21 -0500
Received: (qmail 83657 invoked by uid 3782); 4 Nov 2024 14:13:14 +0100
Received: from muc.de (p4fe1531c.dip0.t-ipconnect.de [79.225.83.28]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 04 Nov 2024 14:13:13 +0100
Received: (qmail 5773 invoked by uid 1000); 4 Nov 2024 13:13:13 -0000
Date: Mon, 4 Nov 2024 13:13:13 +0000
Message-ID: <ZyjIaUbmcZ9bEKiF@HIDDEN>
References: <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN> <864j4nw5qh.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <864j4nw5qh.fsf@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Eli.

On Mon, Nov 04, 2024 at 14:20:06 +0200, Eli Zaretskii wrote:
> > Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
> > Date: Sun, 3 Nov 2024 22:34:58 +0000
> > From: Alan Mackenzie <acm@HIDDEN>

> > +static Lisp_Object
> > +internal_cc_hb (enum handlertype handlertype,

> Please don't use such cryptic names for functions.  There's no need to
> keep function names short if that runs afoul of mnemonics.

I thought that one was clear enough in the context in eval.c.  After
Stefan M's comments, the function isn't suitable for what it tries to
do, so will be disappearing.  But OK, I'll watch out for similar things
in the future.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 04 Nov 2024 13:35:02 +0000
Resent-Message-ID: <handler.66912.B66912.173072726611798 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: acm@HIDDEN, monnier@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173072726611798
          (code B ref 66912); Mon, 04 Nov 2024 13:35:02 +0000
Received: (at 66912) by debbugs.gnu.org; 4 Nov 2024 13:34:26 +0000
Received: from localhost ([127.0.0.1]:39983 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t7xDt-00034E-V7
	for submit <at> debbugs.gnu.org; Mon, 04 Nov 2024 08:34:26 -0500
Received: from eggs.gnu.org ([209.51.188.92]:44974)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1t7xDr-00033z-Le
 for 66912 <at> debbugs.gnu.org; Mon, 04 Nov 2024 08:34:24 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1t7xDl-0001dQ-DI; Mon, 04 Nov 2024 08:34:18 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=/KeIwsdg+LjU2KUSvZJ60GCl2LWRffjXU+bmaitK0vM=; b=Ac3oKi4rqsw2
 GLkbO9r8rT1Urw+BwcE5ys03+o5Z2CoXlvsz7hvdw/DmXAKSnFvb8EbOakyNGYfseetBQlR+U/cFo
 U3cY3nCnORHR16zSCJ//PeVb7tEcJHXwt0OMQkushrH7n++7diVNt/v8x9VKs1+TpOF6mM9f8MyTd
 qeSQM98ByDyEnuZAFM13BJiEq1L6qceHyA6Ojeqr9jE4mIvyVJpaLS64AyunOTXj1WEkbra5QF2Xz
 X7tlyi8D/gnRSdW/Uchu3gg++milWt/k5qBP757WO1dKioYFKLZEJuH9tU1YJdNtmQV5kG/zMpKm8
 mHkTYe6OJ2NWn3dIgaNHjg==;
Date: Mon, 04 Nov 2024 15:34:14 +0200
Message-Id: <86a5efunqh.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <ZyjIaUbmcZ9bEKiF@HIDDEN> (message from Alan Mackenzie on
 Mon, 4 Nov 2024 13:13:13 +0000)
References: <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <864j4nw5qh.fsf@HIDDEN> <ZyjIaUbmcZ9bEKiF@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 4 Nov 2024 13:13:13 +0000
> Cc: monnier@HIDDEN, 66912 <at> debbugs.gnu.org, acm@HIDDEN
> From: Alan Mackenzie <acm@HIDDEN>
> 
> > > +static Lisp_Object
> > > +internal_cc_hb (enum handlertype handlertype,
> 
> > Please don't use such cryptic names for functions.  There's no need to
> > keep function names short if that runs afoul of mnemonics.
> 
> I thought that one was clear enough in the context in eval.c.  After
> Stefan M's comments, the function isn't suitable for what it tries to
> do, so will be disappearing.  But OK, I'll watch out for similar things
> in the future.

Thanks.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 04 Nov 2024 16:13:02 +0000
Resent-Message-ID: <handler.66912.B66912.173073675132524 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173073675132524
          (code B ref 66912); Mon, 04 Nov 2024 16:13:02 +0000
Received: (at 66912) by debbugs.gnu.org; 4 Nov 2024 16:12:31 +0000
Received: from localhost ([127.0.0.1]:40860 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t7zgs-0008SQ-MX
	for submit <at> debbugs.gnu.org; Mon, 04 Nov 2024 11:12:31 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37206)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t7zgq-0008SD-9m
 for 66912 <at> debbugs.gnu.org; Mon, 04 Nov 2024 11:12:29 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CE35144457B;
 Mon,  4 Nov 2024 11:12:21 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1730736740;
 bh=Dq601ewCnseRTuMkA3C+yYLJyK45OzVqieAQURxEW2k=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=o+SpcUniqo+ZUVHEeAVjYPabuyLN4DDDgPmA7TJhoaFHJf6g10YwITS/iivKi1Bk8
 vcLfOYp+XsDKcI0AfYoVJYbC2NlS9Iq16qjjml/CXiZaFcmjcXAStdj0TFSIax4Cjy
 5JA/LgO2L9pcbBF2RDqKr2kdEYVD4S4sLhesWL+M2FmO0YhXFRuYr15oUHRG4vlXco
 A2O5MqyULPP2m7lV36LUo6jztU83WNv3A0K6EF3kNEaPvp/03FL5tXdvfWM1jIA+82
 Fay1Lk3hQzg0MhBLMg3p1m3sO4obtSADSkhKHqIV6m4t13HiEOhcqMS1+RlGxSaSqS
 3oUOfrxm63R1w==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9D5B744457F;
 Mon,  4 Nov 2024 11:12:20 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 768771203DA;
 Mon,  4 Nov 2024 11:12:20 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZyjDerzdpdMJwO5d@HIDDEN> (Alan Mackenzie's message of
 "Mon, 4 Nov 2024 12:52:10 +0000")
Message-ID: <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
References: <ZVE4gyjaCQdw0sbf@ACM> <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
Date: Mon, 04 Nov 2024 11:12:19 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.043 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I don't understand the above code: `handler-bind` is not supposed to
>> call setjmp/longjmp: when the handler of a `handler-bind` gets called,
>> the stack is not unwound.
>
> I started off by just making the HANDLER_BIND case use the same code as
> CONDITION_CASE, and got segfaults.  I've tried to find the places where
> a longjmp gets called for condition-case, but my brain's tired after a
> weekend of heavy coding.

The longjmp is in `unwind_to_catch`, called from `signal_or_quit`, but
we only get there for CONDITION_CASE, not for HANDLER_BIND.

> Given HANDLER_BIND doesn't need the setjmp/longjmp mechanism, it would
> seem there's no sense in combining the HANDLER_BIND and CONDITION_CASE
> cases in internal_cc_hb and friends.  I should just restore the
> condition-case functions to what they were, and add separate new ones
> for handler-bind.

OK.

> I think I see now you're right.  push_handler doesn't push an entry onto
> the binding stack.  I'll amend these comments as soon as I understand
> the code.  I think these lines definitely need comments.

Maybe pointing the reader to the SKIP_CONDITIONS comment in `lisp.h`?

>> Also there's no reason to presume the HANDLER_BIND handler is at the
>> top, so if we wanted to remove it, we'd have to work harder.
> This code is difficult to understand.  What is the purpose of the
> binding block around the call of the handler function?  I think a
> comment here would help.

The `unbind_to` is there because `max_ensure_room` may
`specbind` something.  In 99% of the cases it does nothing.

>> How is this related to `Fprefix_load_file_names`?
> Not closely.  I think I should have propsed two separate patches, rather
> than the big one I did.  Fprefix_load_file_names is what puts the "While
> loading foo.el... " in front of an error message.

Splitting it into two would be good yes.
AFAICT, the `Fprefix_load_file_names` is the part that aims to address
bug#66912.  IMO the other belongs in another bug-report/feature-request?


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 04 Nov 2024 16:36:02 +0000
Resent-Message-ID: <handler.66912.B66912.17307381463280 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17307381463280
          (code B ref 66912); Mon, 04 Nov 2024 16:36:02 +0000
Received: (at 66912) by debbugs.gnu.org; 4 Nov 2024 16:35:46 +0000
Received: from localhost ([127.0.0.1]:40970 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t803O-0000qn-1x
	for submit <at> debbugs.gnu.org; Mon, 04 Nov 2024 11:35:46 -0500
Received: from mail.muc.de ([193.149.48.3]:22979)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t803K-0000qd-IS
 for 66912 <at> debbugs.gnu.org; Mon, 04 Nov 2024 11:35:45 -0500
Received: (qmail 17391 invoked by uid 3782); 4 Nov 2024 17:35:34 +0100
Received: from muc.de (p4fe1531c.dip0.t-ipconnect.de [79.225.83.28]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 04 Nov 2024 17:35:34 +0100
Received: (qmail 17558 invoked by uid 1000); 4 Nov 2024 16:35:34 -0000
Date: Mon, 4 Nov 2024 16:35:34 +0000
Message-ID: <Zyj31vYqNIIJ8b1k@HIDDEN>
References: <jwv34xau1g4.fsf-monnier+emacs@HIDDEN>
 <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZyjDerzdpdMJwO5d@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello again, Stefan.

[ I've just got your latest post, answering my last one.  Thanks!  But
I'm sending you this post anyway, which I'd almost finished. ]

Progress!

On Mon, Nov 04, 2024 at 12:52:10 +0000, Alan Mackenzie wrote:
> On Sun, Nov 03, 2024 at 21:46:42 -0500, Stefan Monnier wrote:
> > Hi Alan,

[ .... ]

> > I don't understand the above code: `handler-bind` is not supposed to
> > call setjmp/longjmp: when the handler of a `handler-bind` gets
> > called, the stack is not unwound.

[ .... ]

> Given HANDLER_BIND doesn't need the setjmp/longjmp mechanism, it would
> seem there's no sense in combining the HANDLER_BIND and CONDITION_CASE
> cases in internal_cc_hb and friends.  I should just restore the
> condition-case functions to what they were, and add separate new ones
> for handler-bind.

I've now done this.  Possibly the new function
internal_condition_case_1_voidstar is superfluous and should be deleted.
Also, not all of the internal_handler_bind* functions are currently
used.

[ .... ]

> > > +		else
> > > +		  call1 (h->val, error);
> > > +	        unbind_to (count, Qnil); /* Removes SKIP_CONDITIONS handler.  */
> > > +	        pop_handler ();		 /* Discards HANDLER_BIND handler.  */

> > These comments don't match my understanding of the code: IIRC the
> > `pop_handler` pops the `SKIP_CONDITIONS` handler.

> I think I see now you're right.  push_handler doesn't push an entry onto
> the binding stack.  I'll amend these comments as soon as I understand
> the code.  I think these lines definitely need comments.

> > Also there's no reason to presume the HANDLER_BIND handler is at the
> > top, so if we wanted to remove it, we'd have to work harder.

> This code is difficult to understand.  What is the purpose of the
> binding block around the call of the handler function?  I think a
> comment here would help.

I've worked this out.  The binding block is to restore the size of the
stack via the unwind_protect set up in the call to max_ensure_room.
I've added a comment to say that.

[ .... ]

I've also amended the doc string of Fhandler_bind_1, saying that the
return value from a handler gets ignored, and clarifying that a normal
return from a handler means the error hasn't been handled.  If you agree
with this, I will make a corresponding amendment to the macro
handler-bind.

Here is the revised part of the patch, just for eval.c:



diff --git a/src/eval.c b/src/eval.c
index d0a2abf0089..79cf9115379 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -256,7 +256,7 @@ restore_stack_limits (Lisp_Object data)
   max_lisp_eval_depth = old_depth;
 }
 
-/* Try and ensure that we have at least B dpeth available.  */
+/* Try and ensure that we have at least B depth available.  */
 
 static void
 max_ensure_room (intmax_t b)
@@ -1450,9 +1450,9 @@ DEFUN ("handler-bind-1", Fhandler_bind_1, Shandler_bind_1, 1, MANY, 0,
 error matches one of CONDITIONS, then the associated HANDLER is
 called with the error as argument.
 HANDLER should either transfer the control via a non-local exit,
-or return normally.
-If it returns normally, the search for an error handler continues
-from where it left off.
+or return normally, should it fail to handle the error.
+If it returns normally, the returned value is ignored, and the
+search for an error handler continues from where it left off.
 
 usage: (handler-bind BODYFUN [CONDITIONS HANDLER]...)  */)
   (ptrdiff_t nargs, Lisp_Object *args)
@@ -1583,7 +1583,7 @@ internal_lisp_condition_case (Lisp_Object var, Lisp_Object bodyform,
 /* Call the function BFUN with no arguments, catching errors within it
    according to HANDLERS.  If there is an error, call HFUN with
    one argument which is the data that describes the error:
-   (SIGNALNAME . DATA)
+   (SIGNALNAME . DATA).
 
    HANDLERS can be a list of conditions to catch.
    If HANDLERS is Qt, catch all errors.
@@ -1662,6 +1662,33 @@ internal_condition_case_2 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object),
     }
 }
 
+/* Like internal_condition_case_2 but the second argument is an arbitrary
+   pointer.  */
+
+Lisp_Object
+internal_condition_case_1_voidstar (Lisp_Object (*bfun) (Lisp_Object, void *),
+				    Lisp_Object arg1,
+				    void *arg2,
+				    Lisp_Object handlers,
+				    Lisp_Object (*hfun) (Lisp_Object))
+{
+  struct handler *c = push_handler (handlers, CONDITION_CASE);
+  if (sys_setjmp (c->jmp))
+    {
+      Lisp_Object val = handlerlist->val;
+      clobbered_eassert (handlerlist == c);
+      handlerlist = handlerlist->next;
+      return hfun (val);
+    }
+  else
+    {
+      Lisp_Object val = bfun (arg1, arg2);
+      eassert (handlerlist == c);
+      handlerlist = c->next;
+      return val;
+    }
+}
+
 /* Like internal_condition_case but call BFUN with NARGS as first,
    and ARGS as second argument.  */
 
@@ -1691,6 +1718,137 @@ internal_condition_case_n (Lisp_Object (*bfun) (ptrdiff_t, Lisp_Object *),
     }
 }
 
+/* Call the function BFUN with no arguments, catching errors within it
+   in a `handler-bind' construct according to HANDLERS.  If there is an
+   error, call HFUN with one argument which is the data that describes
+   the error: (SIGNALNAME . DATA).
+
+   HANDLERS is either a list of conditions to catch, or one of these
+   symbols:
+   If HANDLERS is Qt, catch all errors.
+   If HANDLERS is Qerror, catch all errors, but allow the debugger to
+   run if that is enabled.  */
+
+Lisp_Object
+internal_handler_bind (Lisp_Object (*bfun) (void), Lisp_Object handlers,
+		       Lisp_Object (*hfun) (Lisp_Object))
+{
+  struct handler *c = push_handler (handlers, HANDLER_BIND);
+  /* if (NILP (Flistp (handlers))) */
+  /*   handlers = Fcons (handlers, Qnil); */
+  c->val = Qnil;
+  c->bin_handler = hfun;
+  c->bytecode_dest = 0;
+
+  {
+    Lisp_Object val = bfun ();
+    eassert (handlerlist == c);
+    handlerlist = c->next;
+    return val;
+  }
+}
+
+/* Like internal_handler_bind, but call BFUN with ARG as its argument.  */
+
+Lisp_Object
+internal_handler_bind_1 (Lisp_Object (*bfun) (Lisp_Object), Lisp_Object arg,
+			 Lisp_Object handlers,
+			 Lisp_Object (*hfun) (Lisp_Object))
+{
+  struct handler *c = push_handler (handlers, HANDLER_BIND);
+  /* if (NILP (Flistp (handlers))) */
+  /*   handlers = Fcons (handlers, Qnil); */
+  c->val = Qnil;
+  c->bin_handler = hfun;
+  c->bytecode_dest = 0;
+  {
+    Lisp_Object val = bfun (arg);
+    eassert (handlerlist == c);
+    handlerlist = c->next;
+    return val;
+  }
+}
+
+/* Like internal_handler_bind_1, but call BFUN with ARG1 and ARG2 as
+   its arguments.  */
+
+Lisp_Object
+internal_handler_bind_2 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object),
+			 Lisp_Object arg1,
+			 Lisp_Object arg2,
+			 Lisp_Object handlers,
+			 Lisp_Object (*hfun) (Lisp_Object))
+{
+  struct handler *c = push_handler (handlers, HANDLER_BIND);
+  /* if (NILP (Flistp (handlers))) */
+  /*   handlers = Fcons (handlers, Qnil); */
+  c->val = Qnil;
+  c->bin_handler = hfun;
+  c->bytecode_dest = 0;
+  {
+    Lisp_Object val = bfun (arg1, arg2);
+    eassert (handlerlist == c);
+    handlerlist = c->next;
+    return val;
+  }
+}
+
+/* Like internal_handler_bind_2, but the second argument is an arbitrary
+   pointer.  */
+
+Lisp_Object
+internal_handler_bind_1_voidstar (Lisp_Object (*bfun) (Lisp_Object, void *),
+			 Lisp_Object arg1,
+			 void *arg2,
+			 Lisp_Object handlers,
+			 Lisp_Object (*hfun) (Lisp_Object))
+{
+  struct handler *c = push_handler (handlers, HANDLER_BIND);
+  /* if (NILP (Flistp (handlers))) */
+  /*   handlers = Fcons (handlers, Qnil); */
+  c->val = Qnil;
+  c->bin_handler = hfun;
+  c->bytecode_dest = 0;
+  {
+    Lisp_Object val = bfun (arg1, arg2);
+    eassert (handlerlist == c);
+    handlerlist = c->next;
+    return val;
+  }
+}
+
+/* Like internal_handler_bind, but call BFUN with NARGS as first,
+   and ARGS as second argument.  */
+
+Lisp_Object
+internal_handler_bind_n (Lisp_Object (*bfun) (ptrdiff_t, Lisp_Object *),
+			 ptrdiff_t nargs,
+			 Lisp_Object *args,
+			 Lisp_Object handlers,
+			 Lisp_Object (*hfun) (Lisp_Object err))
+{
+  struct handler *c = push_handler (handlers, HANDLER_BIND);
+    {
+      c->val = Qnil;
+      c->bin_handler = hfun;
+      c->bytecode_dest = 0;
+    }
+  if (sys_setjmp (c->jmp))
+    {
+      Lisp_Object val = handlerlist->val;
+      clobbered_eassert (handlerlist == c);
+      handlerlist = handlerlist->next;
+      return hfun (val);
+    }
+  else
+    {
+      Lisp_Object val = bfun (nargs, args);
+      eassert (handlerlist == c);
+      handlerlist = c->next;
+      return val;
+    }
+}
+
 static Lisp_Object Qcatch_all_memory_full;
 
 /* Like a combination of internal_condition_case_1 and internal_catch.
@@ -1900,9 +2058,12 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool continuable)
 	        max_ensure_room (20);
 	        push_handler (make_fixnum (skip + h->bytecode_dest),
 	                      SKIP_CONDITIONS);
-	        call1 (h->val, error);
-	        unbind_to (count, Qnil);
-	        pop_handler ();
+		if (NILP (h->val))
+		  h->bin_handler (error);
+		else
+		  call1 (h->val, error);
+	        unbind_to (count, Qnil); /* Restore after `max_ensure_room'.  */
+	        pop_handler ();          /* Remove SKIP_CONDITIONS handler.  */
 	      }
 	    continue;
 	  }


> >         Stefan

> -- 
> Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 04 Nov 2024 21:09:02 +0000
Resent-Message-ID: <handler.66912.B66912.17307545274452 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17307545274452
          (code B ref 66912); Mon, 04 Nov 2024 21:09:02 +0000
Received: (at 66912) by debbugs.gnu.org; 4 Nov 2024 21:08:47 +0000
Received: from localhost ([127.0.0.1]:42343 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t84Ja-00019i-FL
	for submit <at> debbugs.gnu.org; Mon, 04 Nov 2024 16:08:47 -0500
Received: from mail.muc.de ([193.149.48.3]:41794)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t84JY-00019a-GM
 for 66912 <at> debbugs.gnu.org; Mon, 04 Nov 2024 16:08:45 -0500
Received: (qmail 28059 invoked by uid 3782); 4 Nov 2024 22:08:36 +0100
Received: from muc.de (p4fe1531c.dip0.t-ipconnect.de [79.225.83.28]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 04 Nov 2024 22:08:36 +0100
Received: (qmail 14886 invoked by uid 1000); 4 Nov 2024 21:08:35 -0000
Date: Mon, 4 Nov 2024 21:08:35 +0000
Message-ID: <Zyk307T10c2qr7e4@HIDDEN>
References: <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Mon, Nov 04, 2024 at 11:12:19 -0500, Stefan Monnier wrote:
> >> I don't understand the above code: `handler-bind` is not supposed to
> >> call setjmp/longjmp: when the handler of a `handler-bind` gets called,
> >> the stack is not unwound.

> > I started off by just making the HANDLER_BIND case use the same code as
> > CONDITION_CASE, and got segfaults.  I've tried to find the places where
> > a longjmp gets called for condition-case, but my brain's tired after a
> > weekend of heavy coding.

> The longjmp is in `unwind_to_catch`, called from `signal_or_quit`, but
> we only get there for CONDITION_CASE, not for HANDLER_BIND.

OK, thanks.

> > Given HANDLER_BIND doesn't need the setjmp/longjmp mechanism, it would
> > seem there's no sense in combining the HANDLER_BIND and CONDITION_CASE
> > cases in internal_cc_hb and friends.  I should just restore the
> > condition-case functions to what they were, and add separate new ones
> > for handler-bind.

> OK.

DONE.

> > I think I see now you're right.  push_handler doesn't push an entry onto
> > the binding stack.  I'll amend these comments as soon as I understand
> > the code.  I think these lines definitely need comments.

> Maybe pointing the reader to the SKIP_CONDITIONS comment in `lisp.h`?

I've put a brief comment on the line saying /* Restore after
`max_ensure_room'.  */

> >> Also there's no reason to presume the HANDLER_BIND handler is at the
> >> top, so if we wanted to remove it, we'd have to work harder.
> > This code is difficult to understand.  What is the purpose of the
> > binding block around the call of the handler function?  I think a
> > comment here would help.

> The `unbind_to` is there because `max_ensure_room` may
> `specbind` something.  In 99% of the cases it does nothing.

OK, thanks, I've got that.

> >> How is this related to `Fprefix_load_file_names`?
> > Not closely.  I think I should have propsed two separate patches, rather
> > than the big one I did.  Fprefix_load_file_names is what puts the "While
> > loading foo.el... " in front of an error message.

> Splitting it into two would be good yes.

OK, I think I agree, even if I would rather not have to advocate for the
second patch again.  ;-)

> AFAICT, the `Fprefix_load_file_names` is the part that aims to address
> bug#66912.  IMO the other belongs in another bug-report/feature-request?

OK, I've separated out the bit that applies "While loading foo.el... "
from all the stuff about handler-bind.  The patch below should, on its
own, fix bug#66912.

What's not there yet is being able to get into the debugger when a byte
compilation is requiring a file, and debug-on-error has been set.  That
will be the subject of the next bug report.

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.



diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index f058fc48cc7..776083468c6 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -1436,8 +1436,9 @@ byte-compile-report-error
 when printing the error message."
   (setq byte-compiler-error-flag t)
   (byte-compile-log-warning
-   (if (stringp error-info) error-info
-     (error-message-string error-info))
+   (prefix-load-file-names
+    (if (stringp error-info) error-info
+      (error-message-string error-info)))
    fill :error))
 
 ;;; sanity-checking arglists
diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index ec947c1215d..4068daf6614 100644
--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -418,7 +418,9 @@ debugger--insert-header
     ;; Debugger entered for an error.
     ('error
      (insert "--Lisp error: ")
-     (insert (backtrace-print-to-string (nth 1 args)))
+     (insert
+      (prefix-load-file-names
+       (backtrace-print-to-string (nth 1 args))))
      (insert ?\n))
     ;; debug-on-call, when the next thing is an eval.
     ('t
@@ -426,8 +428,10 @@ debugger--insert-header
     ;; User calls debug directly.
     (_
      (insert ": ")
-     (insert (backtrace-print-to-string (if (eq (car args) 'nil)
-                                            (cdr args) args)))
+     (insert
+      (prefix-load-file-names
+       (backtrace-print-to-string (if (eq (car args) 'nil)
+                                      (cdr args) args))))
      (insert ?\n))))
 
 
diff --git a/src/keyboard.c b/src/keyboard.c
index 6d28dca9aeb..6758c328038 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -1096,7 +1096,7 @@ DEFUN ("command-error-default-function", Fcommand_error_default_function,
 	  Fdiscard_input ();
 	  bitch_at_user ();
 	}
-
+      context = Fprefix_load_file_names (context);
       print_error_message (data, Qt, SSDATA (context), signal);
     }
   return Qnil;
diff --git a/src/lread.c b/src/lread.c
index ea0398196e3..f81efb3df70 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -236,6 +236,9 @@ #define USE_ANDROID_ASSETS
    check for recursive loads.  */
 
 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;
 
 static int read_emacs_mule_char (int, int (*) (int, Lisp_Object),
                                  Lisp_Object);
@@ -1271,6 +1274,29 @@ close_file_unwind_android_fd (void *ptr)
 
 #endif
 
+DEFUN ("prefix-load-file-names", Fprefix_load_file_names,
+       Sprefix_load_file_names, 1, 1, 0,
+       doc: /* Prefix the string BASE_STRING with a message about each
+file currently being loaded.  Return the resulting string and reset this
+information to null.  */)
+  (Lisp_Object base_string)
+{
+  Lisp_Object result = build_string ("");
+  Lisp_Object while_loading = build_string ("While loading ");
+  Lisp_Object ellipsis = build_string ("... ");
+
+  while (!NILP (Vloads_still_in_progress))
+    {
+      result = concat2 (concat3 (while_loading,
+				 Fcar (Vloads_still_in_progress),
+				 ellipsis),
+			result);
+      Vloads_still_in_progress = Fcdr (Vloads_still_in_progress);
+    }
+  result = concat3 (result, build_string ("\n"), base_string);
+  return result;
+}
+
 DEFUN ("load", Fload, Sload, 1, 5, 0,
        doc: /* Execute a file of Lisp code named FILE.
 First try FILE with `.elc' appended, then try with `.el', then try
@@ -1516,6 +1542,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
 	signal_error ("Recursive load", Fcons (found, Vloads_in_progress));
     record_unwind_protect (record_load_unwind, Vloads_in_progress);
     Vloads_in_progress = Fcons (found, Vloads_in_progress);
+    Vloads_still_in_progress = Vloads_in_progress;
   }
 
   /* All loads are by default dynamic, unless the file itself specifies
@@ -1615,7 +1642,9 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
 	  val = call4 (Vload_source_file_function, found, hist_file_name,
 		       NILP (noerror) ? Qnil : Qt,
 		       (NILP (nomessage) || force_load_messages) ? Qnil : Qt);
-	  return unbind_to (count, val);
+	  unbind_to (count, Qnil);
+	  Vloads_still_in_progress = Vloads_in_progress;
+	  return val;
 	}
     }
 
@@ -1741,6 +1770,8 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
   if (!NILP (Ffboundp (Qdo_after_load_evaluation)))
     call1 (Qdo_after_load_evaluation, hist_file_name) ;
 
+  Vloads_still_in_progress = Vloads_in_progress;
+
   for (int i = 0; i < ARRAYELTS (saved_strings); i++)
     {
       xfree (saved_strings[i].string);
@@ -5772,6 +5803,7 @@ init_lread (void)
   Vload_true_file_name = Qnil;
   Vstandard_input = Qt;
   Vloads_in_progress = Qnil;
+  Vloads_still_in_progress = Qnil;
 }
 
 /* Print a warning that directory intended for use USE and with name
@@ -5819,6 +5851,7 @@ syms_of_lread (void)
   defsubr (&Sintern_soft);
   defsubr (&Sunintern);
   defsubr (&Sget_load_suffixes);
+  defsubr (&Sprefix_load_file_names);
   defsubr (&Sload);
   defsubr (&Seval_buffer);
   defsubr (&Seval_region);
@@ -6138,6 +6171,8 @@ syms_of_lread (void)
 
   Vloads_in_progress = Qnil;
   staticpro (&Vloads_in_progress);
+  Vloads_still_in_progress = Qnil;
+  staticpro (&Vloads_still_in_progress);
 
   DEFSYM (Qhash_table, "hash-table");
   DEFSYM (Qdata, "data");


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 05 Nov 2024 03:28:01 +0000
Resent-Message-ID: <handler.66912.B66912.173077723319202 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173077723319202
          (code B ref 66912); Tue, 05 Nov 2024 03:28:01 +0000
Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 03:27:13 +0000
Received: from localhost ([127.0.0.1]:43067 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8ADo-0004zd-PZ
	for submit <at> debbugs.gnu.org; Mon, 04 Nov 2024 22:27:13 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46928)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t8ADk-0004z3-Ja
 for 66912 <at> debbugs.gnu.org; Mon, 04 Nov 2024 22:27:11 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1DD714448FC;
 Mon,  4 Nov 2024 22:27:02 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1730777220;
 bh=2ChkRfVp0fEXAEAMV4Nv9q72H65QqjsNL8LXtCf2ZKM=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=mylXbri178Gr2zotVGbAxnpCHcA0MAnfo4aG3WqW77tSsv+LJLo2H4CfOBf75xaDo
 CYYNjjVdkm1pAKc4OLY1HG30Vie3Zg7FyPI1vnyNbtkD7G9CXYd1OZ3EtoSlNjfRhv
 1fLf+98re5zivN9VXgsrmoqg7EpY/iJRefvMau8O/l19b6rlZkG7qxXj5jt6Z6cC4t
 VLw8ZgB2rWOHanzVxjuty2sqOldW7RKjUkN3bUDBSN9NtfgwYQXXwFpeQTCp4DFiDB
 rdTnuyXloxGP8q3GwE2VOp2ndZ5nXQQg6in35EQGe5cuIFdh60+adc6T273E/ItU+r
 lreTaHY/Y+inA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DBFA14448CA;
 Mon,  4 Nov 2024 22:27:00 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AF64D120370;
 Mon,  4 Nov 2024 22:27:00 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <Zyk307T10c2qr7e4@HIDDEN> (Alan Mackenzie's message of
 "Mon, 4 Nov 2024 21:08:35 +0000")
Message-ID: <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
References: <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN>
Date: Mon, 04 Nov 2024 22:27:00 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.041 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> 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`.

>  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".

[ BTW, a nice improvement would be to keep track of where we are in the
  outer load when the start the inner load, so that the "While loading"
  message can point to the place where the loading was triggered.  ]


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 05 Nov 2024 04:16:01 +0000
Resent-Message-ID: <handler.66912.B66912.173078012426657 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173078012426657
          (code B ref 66912); Tue, 05 Nov 2024 04:16:01 +0000
Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 04:15:24 +0000
Received: from localhost ([127.0.0.1]:43108 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8AyS-0006vt-BI
	for submit <at> debbugs.gnu.org; Mon, 04 Nov 2024 23:15:24 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58133)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t8AyP-0006rx-FI
 for 66912 <at> debbugs.gnu.org; Mon, 04 Nov 2024 23:15:23 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D4DF6444907;
 Mon,  4 Nov 2024 23:15:14 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1730780113;
 bh=5rD6lmVnfDUScSgDjXFsplhjFJG3cPMPXTlXTXHEeUk=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=FI6YQiRh+bC+fZSIRZIdna+GHK+vbPnXngvV5OAytSjp5lkEDVkVqGeMDHSQtEsse
 QPbZsvxV9KSwKyn1RslVO5ahA4ddmks3x3yTI5837+JEiHl6B6ezT/6mXIXPmO/I2k
 rEqKEkE3fZ29CCktlZusC61dakGyEuOktbTOn0qMhUE3TIjhyLdPaEV9hsJDXM/YC2
 TkBOcJ8aCmN5jVQiIvVOcoLM7YMyjd+jPiJs79lEd0ZeqMKjtbUdCG/KAvpkS6xbS3
 K05BByX5adE+JGI8wpF8sBDw0uuvxk3RpoQ0vE5Bz696XCfJOrpfVRNEhICmFRT2M8
 L54kqag+fgcEg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BDB0B4448FE;
 Mon,  4 Nov 2024 23:15:13 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 92FC612025A;
 Mon,  4 Nov 2024 23:15:13 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvfro65pvl.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Mon, 04 Nov 2024 22:27:00 -0500")
Message-ID: <jwvy11y48xg.fsf-monnier+emacs@HIDDEN>
References: <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
Date: Mon, 04 Nov 2024 23:15:12 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.040 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> 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`.

Also, I think it could report incorrect information in cases such as:

    (condition-case nil
        (load "FILE-A")
      (error ... (forward-sexp) ...))

where an error in the `forward-sexp` might be reported as occurring
"while loading FILE-A" because we didn't revert the
`Vloads_still_in_progress` when unwinding the stack.

I suspect such situations won't occur very often, tho.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 05 Nov 2024 12:19:02 +0000
Resent-Message-ID: <handler.66912.B66912.173080910420702 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: acm@HIDDEN, monnier@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173080910420702
          (code B ref 66912); Tue, 05 Nov 2024 12:19:02 +0000
Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 12:18:24 +0000
Received: from localhost ([127.0.0.1]:43677 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8IVr-0005No-Kd
	for submit <at> debbugs.gnu.org; Tue, 05 Nov 2024 07:18:23 -0500
Received: from eggs.gnu.org ([209.51.188.92]:51252)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1t8IVp-0005Nb-42
 for 66912 <at> debbugs.gnu.org; Tue, 05 Nov 2024 07:18:22 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1t8IVj-0005Gt-6T; Tue, 05 Nov 2024 07:18:15 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=akbxbzV9/OsmU4+pewqTDdFxoLUvar2thj4gOc53GEg=; b=G+uDV7o/RK4t
 DrBo5lSxNkbK5aiVc7ByGFUYttCSwy9pU0/dTJRdlhInnNskCmld850j2H7KJez7DaBkj9ZMxOUbE
 gl6ITLdFlkZ55eSGSYc2MIrmFFkNXF73iyswYUAcvjx4srYize7GNkZ382ejutd+ay6pcVIj8oOgS
 M8w0q+3SMMkcpUE1vbmQb910bmIrrBgAQJFxf8Tqsn7OYE7WlEXSUYqrw5OosaUpQwz1xk4EpOGW6
 i3IbyI3GOFUYgxBOd1xdYtSDv26NgX13xkylOZlcPVy1yKJcvZzsZH5yX2ww5YKGWTogrBaF/FAdc
 m/EvuxP7DK36Rvu5/XKuhw==;
Date: Tue, 05 Nov 2024 14:18:11 +0200
Message-Id: <86ldxxub5o.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <Zyk307T10c2qr7e4@HIDDEN> (message from Alan Mackenzie on
 Mon, 4 Nov 2024 21:08:35 +0000)
References: <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN> <Zyk307T10c2qr7e4@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
> Date: Mon, 4 Nov 2024 21:08:35 +0000
> From: Alan Mackenzie <acm@HIDDEN>
> 
> 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.

On master, I presume?  Not on emacs-30, please.

> +DEFUN ("prefix-load-file-names", Fprefix_load_file_names,
> +       Sprefix_load_file_names, 1, 1, 0,
> +       doc: /* Prefix the string BASE_STRING with a message about each
> +file currently being loaded.  Return the resulting string and reset this
> +information to null.  */)

What "this information"?

Btw, why isn't this function marked as internal by double-dash?  Or
did you want to document it?

Thanks.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 05 Nov 2024 14:05:02 +0000
Resent-Message-ID: <handler.66912.B66912.1730815466522 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: acm@HIDDEN, monnier@HIDDEN, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.1730815466522
          (code B ref 66912); Tue, 05 Nov 2024 14:05:02 +0000
Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 14:04:26 +0000
Received: from localhost ([127.0.0.1]:43928 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8KAU-00008M-0g
	for submit <at> debbugs.gnu.org; Tue, 05 Nov 2024 09:04:26 -0500
Received: from mail.muc.de ([193.149.48.3]:39413)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t8KAR-00008G-Ex
 for 66912 <at> debbugs.gnu.org; Tue, 05 Nov 2024 09:04:24 -0500
Received: (qmail 85864 invoked by uid 3782); 5 Nov 2024 15:04:16 +0100
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 15:04:16 +0100
Received: (qmail 8758 invoked by uid 1000); 5 Nov 2024 14:04:15 -0000
Date: Tue, 5 Nov 2024 14:04:15 +0000
Message-ID: <Zyol34bg-vXFr3Go@HIDDEN>
References: <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN> <86ldxxub5o.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86ldxxub5o.fsf@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hallo, Eli.

On Tue, Nov 05, 2024 at 14:18:11 +0200, Eli Zaretskii wrote:
> > Cc: acm@HIDDEN, 66912 <at> debbugs.gnu.org
> > Date: Mon, 4 Nov 2024 21:08:35 +0000
> > From: Alan Mackenzie <acm@HIDDEN>

> > 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.

> On master, I presume?  Not on emacs-30, please.

Yes, on master.  It's not a documentation fix, and it's not a trivial
fix which is bound to be right.

> > +DEFUN ("prefix-load-file-names", Fprefix_load_file_names,
> > +       Sprefix_load_file_names, 1, 1, 0,
> > +       doc: /* Prefix the string BASE_STRING with a message about each
> > +file currently being loaded.  Return the resulting string and reset this
> > +information to null.  */)

> What "this information"?

It's the variable Vloads_still_in_progress which I want to avoid
exposing to the Lisp world.  I think I need to find a better way to
express that.

But I've become a little uneasy about the way I handle that variable,
and think I need to bind it in the command loop.  Please see my (not yet
written) reply to Stefan M's last post.

> Btw, why isn't this function marked as internal by double-dash?  Or
> did you want to document it?

It's used by other libraries, notably the debugger and the byte
compiler.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 05 Nov 2024 14:07:01 +0000
Resent-Message-ID: <handler.66912.B66912.1730815599998 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Alan Mackenzie <acm@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.1730815599998
          (code B ref 66912); Tue, 05 Nov 2024 14:07:01 +0000
Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 14:06:39 +0000
Received: from localhost ([127.0.0.1]:43940 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8KCd-0000G2-3N
	for submit <at> debbugs.gnu.org; Tue, 05 Nov 2024 09:06:39 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50790)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t8KCa-0000Fh-Ay
 for 66912 <at> debbugs.gnu.org; Tue, 05 Nov 2024 09:06:37 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C9C24100180;
 Tue,  5 Nov 2024 09:06:27 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1730815586;
 bh=RwLvguz3tsAXRryqtW37mTsyysW2H/KdpqIpmrhSpxo=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=mk9BoqwqxUre2fu9RqDPlZMFpEA61LlKSGsHUBe0QKPLTfOOxgo0rOzzSVvRfmUFU
 nuo9EulbI0EYJhaSUZy/kg0OMckx5TPoI8qy1K2YA4DbUNHoju3ix3UnHSKuaEBpvT
 1mKk36eFejJyU9JsYUc3l/75ry6ymnpAdAmhZ47e4ETseuKEnmdS+UgIy2s6XnOjRw
 PQ65Ryc08tF6zVvT0Km8BOJAiIBMr8c+a2KKoDb3WLtjoXlON54v/anEXR5xKmNV/U
 92P8GH+a+tldMGWEQJfd7Yai4eexhH08MFQWcQuCi/ONhU/ZRyGzEmGFHTck6lNyiC
 xOZKc83KcCZAQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B7CC7100043;
 Tue,  5 Nov 2024 09:06:26 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8C2531202EF;
 Tue,  5 Nov 2024 09:06:26 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <86ldxxub5o.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 05 Nov
 2024 14:18:11 +0200")
Message-ID: <jwvcyj94w5o.fsf-monnier+emacs@HIDDEN>
References: <ZyEwfwDHEenwpkkr@HIDDEN>
 <jwvjzdpxyag.fsf-monnier+emacs@HIDDEN>
 <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN> <86ldxxub5o.fsf@HIDDEN>
Date: Tue, 05 Nov 2024 09:06:23 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.090 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> +DEFUN ("prefix-load-file-names", Fprefix_load_file_names,
>> +       Sprefix_load_file_names, 1, 1, 0,
>> +       doc: /* Prefix the string BASE_STRING with a message about each
>> +file currently being loaded.  Return the resulting string and reset this
>> +information to null.  */)
>
> What "this information"?

Oh, also, I missed it but: "file currently being loaded" is not right
(by the time we use this function, we're usually not loading the file
any more, because of the error: we already unwound the stack and exited
the `load`s).

> Btw, why isn't this function marked as internal by double-dash?
> Or did you want to document it?

Given its odd calling convention (it strongly depends on timing and on
the current implementation strategy), I'd recommend a double dash
because if we ever care to fix its shortcomings we'd have to change it
in an incompatible way.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 05 Nov 2024 14:55:02 +0000
Resent-Message-ID: <handler.66912.B66912.17308184756478 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17308184756478
          (code B ref 66912); Tue, 05 Nov 2024 14:55:02 +0000
Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 14:54:35 +0000
Received: from localhost ([127.0.0.1]:44037 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8Kx1-0001gQ-E0
	for submit <at> debbugs.gnu.org; Tue, 05 Nov 2024 09:54:35 -0500
Received: from mail.muc.de ([193.149.48.3]:51145)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t8Kwy-0001gI-N0
 for 66912 <at> debbugs.gnu.org; Tue, 05 Nov 2024 09:54:33 -0500
Received: (qmail 42315 invoked by uid 3782); 5 Nov 2024 15:54:25 +0100
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 15:54:25 +0100
Received: (qmail 9400 invoked by uid 1000); 5 Nov 2024 14:54:24 -0000
Date: Tue, 5 Nov 2024 14:54:24 +0000
Message-ID: <ZyoxoMo8u23e_aHD@HIDDEN>
References: <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Mon, Nov 04, 2024 at 22:27:00 -0500, Stefan Monnier wrote:
> > 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, a nice improvement would be to keep track of where we are in the
>   outer load when the start the inner load, so that the "While loading"
>   message can point to the place where the loading was triggered.  ]

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:

While loading foo.el line 42... While loading bar.elc... While loading baz.el... \n
Wrong type argument: listp, baz

I'm sure this wouldn't be too difficult.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 05 Nov 2024 19:01:02 +0000
Resent-Message-ID: <handler.66912.B66912.17308332615004 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17308332615004
          (code B ref 66912); Tue, 05 Nov 2024 19:01:02 +0000
Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 19:01:01 +0000
Received: from localhost ([127.0.0.1]:37908 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8OnU-0001Ie-Un
	for submit <at> debbugs.gnu.org; Tue, 05 Nov 2024 14:01:01 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42322)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t8OnS-0001IK-E2
 for 66912 <at> debbugs.gnu.org; Tue, 05 Nov 2024 14:00:59 -0500
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==
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)
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)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZyoxoMo8u23e_aHD@HIDDEN> (Alan Mackenzie's message of
 "Tue, 5 Nov 2024 14:54:24 +0000")
Message-ID: <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
References: <ZyKqjSkBma6OQRJn@HIDDEN>
 <jwvcyjhxnc9.fsf-monnier+emacs@HIDDEN>
 <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
 <ZyoxoMo8u23e_aHD@HIDDEN>
Date: Tue, 05 Nov 2024 14:00:43 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.211 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> > 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 05 Nov 2024 20:34:01 +0000
Resent-Message-ID: <handler.66912.B66912.173083881320712 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173083881320712
          (code B ref 66912); Tue, 05 Nov 2024 20:34:01 +0000
Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 20:33:33 +0000
Received: from localhost ([127.0.0.1]:38095 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8QF3-0005O0-9P
	for submit <at> debbugs.gnu.org; Tue, 05 Nov 2024 15:33:33 -0500
Received: from mail.muc.de ([193.149.48.3]:22073)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t8QF1-0005Nl-CX
 for 66912 <at> debbugs.gnu.org; Tue, 05 Nov 2024 15:33:32 -0500
Received: (qmail 27249 invoked by uid 3782); 5 Nov 2024 21:33:25 +0100
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
Received: (qmail 15237 invoked by uid 1000); 5 Nov 2024 20:33:23 -0000
Date: Tue, 5 Nov 2024 20:33:23 +0000
Message-ID: <ZyqBE6HALcSno8g0@HIDDEN>
References: <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
 <ZyoxoMo8u23e_aHD@HIDDEN>
 <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

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).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 05 Nov 2024 23:21:01 +0000
Resent-Message-ID: <handler.66912.B66912.173084881317719 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173084881317719
          (code B ref 66912); Tue, 05 Nov 2024 23:21:01 +0000
Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 23:20:13 +0000
Received: from localhost ([127.0.0.1]:38507 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8SqL-0004bi-7x
	for submit <at> debbugs.gnu.org; Tue, 05 Nov 2024 18:20:13 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7486)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t8SqI-0004XH-PS
 for 66912 <at> debbugs.gnu.org; Tue, 05 Nov 2024 18:20:11 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6B886100180;
 Tue,  5 Nov 2024 18:20:04 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1730848803;
 bh=ueSCAanZ7VZ2D8PZxN4E7zppJI0F8UJ7r9ULqQWcxbY=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=atZrNKZKVhGO3TWunQRoPN7GDUpR/5KnuGYFg4EqniE6YIdnU1XzM2IiPyPTl8v6L
 18QiAtuLHrhTR/ChdaPsUv0/tGzZ4v8uNTjwmNW7ethARwGW2mXjZM8+SlImyZ/+jm
 yeX4E8maRCNGS2jSDC5xJ0I54yD9EJxdJ5NaYgbh57X7efRK2RIdTItax1FTf5lYG6
 oqqmCRh5iguf4LZWGPZjrslER/8RGBwiJ/05svBwxhF81sjTnVg42W/MkeXh5hE9vw
 Nwghx7QVuVLDiABreKuG7M/YOOU9wjKiTHOmWHyAp3X+Gqg6pToLGFIbESau9JxOb9
 SiGljHLmMsEew==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B10BF100043;
 Tue,  5 Nov 2024 18:20:03 -0500 (EST)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A28511204EC;
 Tue,  5 Nov 2024 18:20:03 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZyqBE6HALcSno8g0@HIDDEN> (Alan Mackenzie's message of
 "Tue, 5 Nov 2024 20:33:23 +0000")
Message-ID: <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
References: <ZyYtYBLLKqas8r7B@HIDDEN>
 <jwvo72xd7z9.fsf-monnier+emacs@HIDDEN>
 <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
 <ZyoxoMo8u23e_aHD@HIDDEN>
 <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
 <ZyqBE6HALcSno8g0@HIDDEN>
Date: Tue, 05 Nov 2024 18:20:03 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.182 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> There needs to be some mechanism for resetting this variable to Qnil,
> should the error handler fail to access it.

I was thinking we wouldn't bother, just like the we don't bother
emptying the match-data after we used it.

> 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.

Yes, we may want to locally let-bind the var to preserve it, similarly
to the occasional use of `save-match-data`.

> 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.

Indeed, which is also why I was pointing out that the thing could be
generalized to other context information, so we don't get fixated on `load`.

> 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.

If the let-binding that preserves the new var is performed around the
call to the debugger (rather than being performed inside the debugger
itself), we should be OK.

> I think your idea might be better than my current patch, but I doubt
> it's going to be much simpler.

The thing I like is that it should be a better replacement for
`Vsignaling_function` (which is currently a very low-tech feature which
works only half the time).

>> > 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.

Yes, there's no hurry.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 06 Nov 2024 16:25:01 +0000
Resent-Message-ID: <handler.66912.B66912.173091024731594 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173091024731594
          (code B ref 66912); Wed, 06 Nov 2024 16:25:01 +0000
Received: (at 66912) by debbugs.gnu.org; 6 Nov 2024 16:24:07 +0000
Received: from localhost ([127.0.0.1]:45235 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8ipC-0008DV-Js
	for submit <at> debbugs.gnu.org; Wed, 06 Nov 2024 11:24:07 -0500
Received: from mail.muc.de ([193.149.48.3]:59004)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t8ip7-0008Cw-Vx
 for 66912 <at> debbugs.gnu.org; Wed, 06 Nov 2024 11:24:04 -0500
Received: (qmail 85540 invoked by uid 3782); 6 Nov 2024 17:23:55 +0100
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 17:23:54 +0100
Received: (qmail 32420 invoked by uid 1000); 6 Nov 2024 16:23:53 -0000
Date: Wed, 6 Nov 2024 16:23:53 +0000
Message-ID: <ZyuYGd1IBLu4el5d@HIDDEN>
References: <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
 <ZyoxoMo8u23e_aHD@HIDDEN>
 <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
 <ZyqBE6HALcSno8g0@HIDDEN>
 <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

I've implemented your suggestion, and it mostly works.  Let me know if
you'd like to see the patch (for which I'd have to tidy up the source
code).  But ....

On Tue, Nov 05, 2024 at 18:20:03 -0500, Stefan Monnier wrote:
> > There needs to be some mechanism for resetting this variable to Qnil,
> > should the error handler fail to access it.

> 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.
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.

This is a Bad Thing.  Do you have any suggestions for a fix?  Things
like artificially setting or binding Vloads_in_progress to nil don't
seem like proper fixes.

> > 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.

> Yes, we may want to locally let-bind the var to preserve it, similarly
> to the occasional use of `save-match-data`.

I don't think this is a problem any more.  I only set
Vloads_in_progress_at_error (as I've renamed it as) when there's an
actual error, not the handling of a condition-case thing, or the like.

> > 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.

> Indeed, which is also why I was pointing out that the thing could be
> generalized to other context information, so we don't get fixated on `load`.

That wasn't quite the sense I meant it in.  ;-)

> > 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.

> If the let-binding that preserves the new var is performed around the
> call to the debugger (rather than being performed inside the debugger
> itself), we should be OK.

> > I think your idea might be better than my current patch, but I doubt
> > it's going to be much simpler.

I've tried it, and the above problem seems definitely to make it less
simple than the approach I originally took (which currently works).

Maybe we should go back to my original working approach.

> The thing I like is that it should be a better replacement for
> `Vsignaling_function` (which is currently a very low-tech feature which
> works only half the time).

OK, I haven't looked at that.

> >> > 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.

> Yes, there's no hurry.

Indeed not.  The bug has just passed its 1-year anniversary.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 06 Nov 2024 18:52:02 +0000
Resent-Message-ID: <handler.66912.B66912.173091908425745 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173091908425745
          (code B ref 66912); Wed, 06 Nov 2024 18:52:02 +0000
Received: (at 66912) by debbugs.gnu.org; 6 Nov 2024 18:51:24 +0000
Received: from localhost ([127.0.0.1]:45431 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8l7j-0006hB-Nv
	for submit <at> debbugs.gnu.org; Wed, 06 Nov 2024 13:51:24 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42477)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t8l7h-0006gy-HP
 for 66912 <at> debbugs.gnu.org; Wed, 06 Nov 2024 13:51:22 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6C70280A48;
 Wed,  6 Nov 2024 13:51:15 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1730919074;
 bh=p6mlQ3h+4LyMLyh5MyT/xMrvVdWnOK8O+mXK7jEfHKo=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=BlSH12d2FGCHLVFtMuAizXgDr8zYdCl3JvvS3f6VYZK40bRyZe+77qj/uZr5fcWpU
 tUM2BCctO14fOHu2hRM9/nmEMOxE7bx9kMqyGxnrjt7wBYEq6A/NlmFP0pzD/W+b5i
 lXmaF6llZn+De4vMbaqU2yyeGONcRWB0Mtqah6MAN91tpqM1k8yFskWUrVOy/9yoxq
 HHsi5jwbmE8VIMacnROt6MayEkT9hJv/5fFmB/lGR4i/RdXsRfWxLYCuDOxEBZW74/
 6MsIdt1Niw40KaZfi3eXSfeZKDkV3RZ0FLSoZ+dGNKCJHsdW+RIjaRECTDBl9Tw8Ar
 IvzY3tqF5xrlA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 91B1E8056D;
 Wed,  6 Nov 2024 13:51:14 -0500 (EST)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 81285120312;
 Wed,  6 Nov 2024 13:51:14 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZyuYGd1IBLu4el5d@HIDDEN> (Alan Mackenzie's message of
 "Wed, 6 Nov 2024 16:23:53 +0000")
Message-ID: <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
References: <Zyf6ki4nk8titM2D@HIDDEN>
 <jwvo72v92aa.fsf-monnier+emacs@HIDDEN>
 <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
 <ZyoxoMo8u23e_aHD@HIDDEN>
 <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
 <ZyqBE6HALcSno8g0@HIDDEN>
 <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
 <ZyuYGd1IBLu4el5d@HIDDEN>
Date: Wed, 06 Nov 2024 13:51:05 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.172 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> 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.

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".

> 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 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`.

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))))

> 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.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 06 Nov 2024 20:13:02 +0000
Resent-Message-ID: <handler.66912.B66912.17309239737413 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17309239737413
          (code B ref 66912); Wed, 06 Nov 2024 20:13:02 +0000
Received: (at 66912) by debbugs.gnu.org; 6 Nov 2024 20:12:53 +0000
Received: from localhost ([127.0.0.1]:45590 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8mOb-0001vV-66
	for submit <at> debbugs.gnu.org; Wed, 06 Nov 2024 15:12:53 -0500
Received: from mail.muc.de ([193.149.48.3]:19320)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t8mOY-0001vF-FL
 for 66912 <at> debbugs.gnu.org; Wed, 06 Nov 2024 15:12:51 -0500
Received: (qmail 44047 invoked by uid 3782); 6 Nov 2024 21:12:44 +0100
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
Received: (qmail 5611 invoked by uid 1000); 6 Nov 2024 20:12:43 -0000
Date: Wed, 6 Nov 2024 20:12:43 +0000
Message-ID: <ZyvNu25qkpBvGa47@HIDDEN>
References: <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
 <ZyoxoMo8u23e_aHD@HIDDEN>
 <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
 <ZyqBE6HALcSno8g0@HIDDEN>
 <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
 <ZyuYGd1IBLu4el5d@HIDDEN>
 <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

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).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 07 Nov 2024 04:01:01 +0000
Resent-Message-ID: <handler.66912.B66912.173095201631029 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173095201631029
          (code B ref 66912); Thu, 07 Nov 2024 04:01:01 +0000
Received: (at 66912) by debbugs.gnu.org; 7 Nov 2024 04:00:16 +0000
Received: from localhost ([127.0.0.1]:46805 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t8tgu-00083s-8X
	for submit <at> debbugs.gnu.org; Wed, 06 Nov 2024 23:00:16 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43527)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t8tgr-00080t-Qz
 for 66912 <at> debbugs.gnu.org; Wed, 06 Nov 2024 23:00:14 -0500
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==
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)
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)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZyvNu25qkpBvGa47@HIDDEN> (Alan Mackenzie's message of
 "Wed, 6 Nov 2024 20:12:43 +0000")
Message-ID: <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
References: <ZyjDerzdpdMJwO5d@HIDDEN>
 <jwvv7x36l7h.fsf-monnier+emacs@HIDDEN>
 <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
 <ZyoxoMo8u23e_aHD@HIDDEN>
 <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
 <ZyqBE6HALcSno8g0@HIDDEN>
 <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
 <ZyuYGd1IBLu4el5d@HIDDEN>
 <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
 <ZyvNu25qkpBvGa47@HIDDEN>
Date: Wed, 06 Nov 2024 18:14:18 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.176 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>>     (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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 07 Nov 2024 12:39:01 +0000
Resent-Message-ID: <handler.66912.B66912.173098308920901 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173098308920901
          (code B ref 66912); Thu, 07 Nov 2024 12:39:01 +0000
Received: (at 66912) by debbugs.gnu.org; 7 Nov 2024 12:38:09 +0000
Received: from localhost ([127.0.0.1]:47495 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t91m4-0005R2-97
	for submit <at> debbugs.gnu.org; Thu, 07 Nov 2024 07:38:08 -0500
Received: from mail.muc.de ([193.149.48.3]:49374)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t91m0-0005QV-R1
 for 66912 <at> debbugs.gnu.org; Thu, 07 Nov 2024 07:38:07 -0500
Received: (qmail 5493 invoked by uid 3782); 7 Nov 2024 13:37:57 +0100
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 13:37:57 +0100
Received: (qmail 5864 invoked by uid 1000); 7 Nov 2024 12:37:57 -0000
Date: Thu, 7 Nov 2024 12:37:56 +0000
Message-ID: <Zyy0pB9a-6Bx_uDx@HIDDEN>
References: <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
 <ZyoxoMo8u23e_aHD@HIDDEN>
 <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
 <ZyqBE6HALcSno8g0@HIDDEN>
 <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
 <ZyuYGd1IBLu4el5d@HIDDEN>
 <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
 <ZyvNu25qkpBvGa47@HIDDEN>
 <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Wed, Nov 06, 2024 at 18:14:18 -0500, Stefan Monnier wrote:
> >>     (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 don't understand why you say it doesn't make sense:

> An error in signaled from with a => 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.

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.

> >> > 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.

> > 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, ....

Something very similar, if not the same, was the original handling of
byte-compile-form-stack.  There a form was pushed onto the stack at the
start of a byte-compile- function, and popped off again at its end,
without using binding.  In the case of an error, where the binding stack
gets unwound, byte-compile-form-stack retained its value at the time of
the error.  It worked without trouble (as far as I'm aware).

>   .... 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" 🙂

I will do that.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 07 Nov 2024 15:05:02 +0000
Resent-Message-ID: <handler.66912.B66912.173099188414943 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173099188414943
          (code B ref 66912); Thu, 07 Nov 2024 15:05:02 +0000
Received: (at 66912) by debbugs.gnu.org; 7 Nov 2024 15:04:44 +0000
Received: from localhost ([127.0.0.1]:49223 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t943w-0003sv-1s
	for submit <at> debbugs.gnu.org; Thu, 07 Nov 2024 10:04:44 -0500
Received: from mail.muc.de ([193.149.48.3]:61234)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t943s-0003sf-VA
 for 66912 <at> debbugs.gnu.org; Thu, 07 Nov 2024 10:04:41 -0500
Received: (qmail 96662 invoked by uid 3782); 7 Nov 2024 16:04:33 +0100
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 16:04:32 +0100
Received: (qmail 18756 invoked by uid 1000); 7 Nov 2024 15:04:32 -0000
Date: Thu, 7 Nov 2024 15:04:32 +0000
Message-ID: <ZyzXAJwN3DdH3W6C@HIDDEN>
References: <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
 <ZyoxoMo8u23e_aHD@HIDDEN>
 <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
 <ZyqBE6HALcSno8g0@HIDDEN>
 <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
 <ZyuYGd1IBLu4el5d@HIDDEN>
 <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
 <ZyvNu25qkpBvGa47@HIDDEN>
 <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello again, Stefan.

On Wed, Nov 06, 2024 at 18:14:18 -0500, Stefan Monnier wrote:

[ .... ]

> > 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" 🙂

DONE.

Here is, perhaps, the final version of my patch, containing the revised
doc comment for Vloads_still_in_progress, and for
Fprefix_loads_in_progress.

Maybe, just maybe, I can commit this as the fix to bug#66912.



diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index f058fc48cc7..776083468c6 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -1436,8 +1436,9 @@ byte-compile-report-error
 when printing the error message."
   (setq byte-compiler-error-flag t)
   (byte-compile-log-warning
-   (if (stringp error-info) error-info
-     (error-message-string error-info))
+   (prefix-load-file-names
+    (if (stringp error-info) error-info
+      (error-message-string error-info)))
    fill :error))
 
 ;;; sanity-checking arglists
diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index ec947c1215d..4068daf6614 100644
--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -418,7 +418,9 @@ debugger--insert-header
     ;; Debugger entered for an error.
     ('error
      (insert "--Lisp error: ")
-     (insert (backtrace-print-to-string (nth 1 args)))
+     (insert
+      (prefix-load-file-names
+       (backtrace-print-to-string (nth 1 args))))
      (insert ?\n))
     ;; debug-on-call, when the next thing is an eval.
     ('t
@@ -426,8 +428,10 @@ debugger--insert-header
     ;; User calls debug directly.
     (_
      (insert ": ")
-     (insert (backtrace-print-to-string (if (eq (car args) 'nil)
-                                            (cdr args) args)))
+     (insert
+      (prefix-load-file-names
+       (backtrace-print-to-string (if (eq (car args) 'nil)
+                                      (cdr args) args))))
      (insert ?\n))))
 
 
diff --git a/src/keyboard.c b/src/keyboard.c
index 6d28dca9aeb..5d615233f15 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -1096,7 +1096,7 @@ DEFUN ("command-error-default-function", Fcommand_error_default_function,
 	  Fdiscard_input ();
 	  bitch_at_user ();
 	}
-
+      context = Fprefix_load_file_names (context);
       print_error_message (data, Qt, SSDATA (context), signal);
     }
   return Qnil;
@@ -1109,6 +1109,11 @@ DEFUN ("command-error-default-function", Fcommand_error_default_function,
    This level has the catches for exiting/returning to editor command loop.
    It returns nil to exit recursive edit, t to abort it.  */
 
+static void restore_Vloads_still_in_progress (Lisp_Object arg)
+{
+  Vloads_still_in_progress = arg;
+}
+
 Lisp_Object
 command_loop (void)
 {
@@ -1137,6 +1142,10 @@ command_loop (void)
   else
     while (1)
       {
+	specpdl_ref ccount = SPECPDL_INDEX ();
+
+	record_unwind_protect (restore_Vloads_still_in_progress,
+			       Vloads_still_in_progress);
 	internal_catch (Qtop_level, top_level_1, Qnil);
 	internal_catch (Qtop_level, command_loop_2, Qerror);
 	executing_kbd_macro = Qnil;
@@ -1144,6 +1153,7 @@ command_loop (void)
 	/* End of file in -batch run causes exit here.  */
 	if (noninteractive)
 	  Fkill_emacs (Qt, Qnil);
+	unbind_to (ccount, Qnil);
       }
 }
 
diff --git a/src/lisp.h b/src/lisp.h
index 5ef97047f76..e7eecba96f6 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4794,6 +4794,7 @@ #define FLOAT_TO_STRING_BUFSIZE 350
   ATTRIBUTE_FORMAT_PRINTF (5, 0);
 
 /* Defined in lread.c.  */
+extern Lisp_Object Vloads_still_in_progress;
 extern Lisp_Object intern_1 (const char *, ptrdiff_t);
 extern Lisp_Object intern_c_string_1 (const char *, ptrdiff_t);
 extern Lisp_Object intern_driver (Lisp_Object, Lisp_Object, Lisp_Object);
diff --git a/src/lread.c b/src/lread.c
index ea0398196e3..234f3b1cd25 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -234,9 +234,17 @@ #define USE_ANDROID_ASSETS
 
 /* A list of file names for files being loaded in Fload.  Used to
    check for recursive loads.  */
-
 static Lisp_Object Vloads_in_progress;
 
+/* The same as the above, but is bound only in the command loop, not in
+   Fload.  It is set to the value of Floads_in_progress at the start and
+   end of Fload.  In the event of an error being signaled and the
+   binding stack being unwound, this variable keeps its value.  Its sole
+   use is to supplement error messages, giving the names of the stack of
+   files currently being loaded.  See Fprefix_load_file_names in this
+   file.  */
+Lisp_Object Vloads_still_in_progress;
+
 static int read_emacs_mule_char (int, int (*) (int, Lisp_Object),
                                  Lisp_Object);
 
@@ -1271,6 +1279,34 @@ close_file_unwind_android_fd (void *ptr)
 
 #endif
 
+DEFUN ("prefix-load-file-names", Fprefix_load_file_names,
+       Sprefix_load_file_names, 1, 1, 0,
+       doc: /* Prefix the string BASE_STRING with a message about each
+file currently being loaded.  Return the resulting string and reset the
+internal variable holding this information to nil.  */)
+  (Lisp_Object base_string)
+{
+  if (NILP (Vloads_still_in_progress))
+    return base_string;
+  else
+    {
+      Lisp_Object result = build_string ("");
+      Lisp_Object while_loading = build_string ("While loading ");
+      Lisp_Object ellipsis = build_string ("... ");
+
+      while (!NILP (Vloads_still_in_progress))
+	{
+	  result = concat2 (concat3 (while_loading,
+				     Fcar (Vloads_still_in_progress),
+				     ellipsis),
+			    result);
+	  Vloads_still_in_progress = Fcdr (Vloads_still_in_progress);
+	}
+      result = concat3 (result, build_string ("\n"), base_string);
+      return result;
+    }
+}
+
 DEFUN ("load", Fload, Sload, 1, 5, 0,
        doc: /* Execute a file of Lisp code named FILE.
 First try FILE with `.elc' appended, then try with `.el', then try
@@ -1516,6 +1552,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
 	signal_error ("Recursive load", Fcons (found, Vloads_in_progress));
     record_unwind_protect (record_load_unwind, Vloads_in_progress);
     Vloads_in_progress = Fcons (found, Vloads_in_progress);
+    Vloads_still_in_progress = Vloads_in_progress;
   }
 
   /* All loads are by default dynamic, unless the file itself specifies
@@ -1615,7 +1652,9 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
 	  val = call4 (Vload_source_file_function, found, hist_file_name,
 		       NILP (noerror) ? Qnil : Qt,
 		       (NILP (nomessage) || force_load_messages) ? Qnil : Qt);
-	  return unbind_to (count, val);
+	  unbind_to (count, Qnil);
+	  Vloads_still_in_progress = Vloads_in_progress;
+	  return val;
 	}
     }
 
@@ -1741,6 +1780,8 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
   if (!NILP (Ffboundp (Qdo_after_load_evaluation)))
     call1 (Qdo_after_load_evaluation, hist_file_name) ;
 
+  Vloads_still_in_progress = Vloads_in_progress;
+
   for (int i = 0; i < ARRAYELTS (saved_strings); i++)
     {
       xfree (saved_strings[i].string);
@@ -5772,6 +5813,7 @@ init_lread (void)
   Vload_true_file_name = Qnil;
   Vstandard_input = Qt;
   Vloads_in_progress = Qnil;
+  Vloads_still_in_progress = Qnil;
 }
 
 /* Print a warning that directory intended for use USE and with name
@@ -5819,6 +5861,7 @@ syms_of_lread (void)
   defsubr (&Sintern_soft);
   defsubr (&Sunintern);
   defsubr (&Sget_load_suffixes);
+  defsubr (&Sprefix_load_file_names);
   defsubr (&Sload);
   defsubr (&Seval_buffer);
   defsubr (&Seval_region);
@@ -6138,6 +6181,8 @@ syms_of_lread (void)
 
   Vloads_in_progress = Qnil;
   staticpro (&Vloads_in_progress);
+  Vloads_still_in_progress = Qnil;
+  staticpro (&Vloads_still_in_progress);
 
   DEFSYM (Qhash_table, "hash-table");
   DEFSYM (Qdata, "data");


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 07 Nov 2024 16:10:02 +0000
Resent-Message-ID: <handler.66912.B66912.173099577226182 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173099577226182
          (code B ref 66912); Thu, 07 Nov 2024 16:10:02 +0000
Received: (at 66912) by debbugs.gnu.org; 7 Nov 2024 16:09:32 +0000
Received: from localhost ([127.0.0.1]:49318 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t954d-0006oE-QN
	for submit <at> debbugs.gnu.org; Thu, 07 Nov 2024 11:09:32 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57192)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t954Z-0006md-Fm
 for 66912 <at> debbugs.gnu.org; Thu, 07 Nov 2024 11:09:30 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id EB806100383;
 Thu,  7 Nov 2024 11:09:20 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1730995760;
 bh=1qIJN0dTBnNpcjIljH6hvU/K+AT3n/n6AzuypnHA+sw=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=I2lWbFyyRmAMs+WFI4q0MfaarJhBOXWLV/7u5zxgHKphQdUmiBQ4yjHxZsQJHKsHm
 0QA41hHoXOrqnGd08MYOwDKK7SwwpYT7pH//l0zxDDm14ixWfbTH8vrFa0klFMtuYj
 uUNk/OGbWZ95FfzsYbt3GbENy/keND/wQsxBiXcJLcyXBb2KBR+WGScvwvpWSrzctY
 uGvDehK3useGpOYBF5h0x1filxch2LDu3oP+1TztJZgIg/HtVeMp97cOxjhO6FhSGc
 TQNeUAxuEcBDIEdFR7SYEQgKXDhN6WSXr6PAMA67lzclqYIHyMVVhMSf8ofsZW6zI1
 bvceNeIviemQg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 32E45100126;
 Thu,  7 Nov 2024 11:09:20 -0500 (EST)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 20AE81202FD;
 Thu,  7 Nov 2024 11:09:20 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <Zyy0pB9a-6Bx_uDx@HIDDEN> (Alan Mackenzie's message of
 "Thu, 7 Nov 2024 12:37:56 +0000")
Message-ID: <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
References: <Zyk307T10c2qr7e4@HIDDEN>
 <jwvfro65pvl.fsf-monnier+emacs@HIDDEN>
 <ZyoxoMo8u23e_aHD@HIDDEN>
 <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
 <ZyqBE6HALcSno8g0@HIDDEN>
 <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
 <ZyuYGd1IBLu4el5d@HIDDEN>
 <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
 <ZyvNu25qkpBvGa47@HIDDEN>
 <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
 <Zyy0pB9a-6Bx_uDx@HIDDEN>
Date: Thu, 07 Nov 2024 11:09:19 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.176 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> 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?

>> >> > 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.

> 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.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 07 Nov 2024 17:16:02 +0000
Resent-Message-ID: <handler.66912.B66912.17309997605995 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17309997605995
          (code B ref 66912); Thu, 07 Nov 2024 17:16:02 +0000
Received: (at 66912) by debbugs.gnu.org; 7 Nov 2024 17:16:00 +0000
Received: from localhost ([127.0.0.1]:49444 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t966x-0001Yd-Qt
	for submit <at> debbugs.gnu.org; Thu, 07 Nov 2024 12:16:00 -0500
Received: from mail.muc.de ([193.149.48.3]:24683)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t966v-0001YK-5p
 for 66912 <at> debbugs.gnu.org; Thu, 07 Nov 2024 12:15:58 -0500
Received: (qmail 71844 invoked by uid 3782); 7 Nov 2024 18:15:50 +0100
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
Received: (qmail 20277 invoked by uid 1000); 7 Nov 2024 17:15:49 -0000
Date: Thu, 7 Nov 2024 17:15:49 +0000
Message-ID: <Zyz1xWXcfEghUWOa@HIDDEN>
References: <ZyoxoMo8u23e_aHD@HIDDEN>
 <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
 <ZyqBE6HALcSno8g0@HIDDEN>
 <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
 <ZyuYGd1IBLu4el5d@HIDDEN>
 <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
 <ZyvNu25qkpBvGa47@HIDDEN>
 <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
 <Zyy0pB9a-6Bx_uDx@HIDDEN>
 <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

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).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 08 Nov 2024 13:43:02 +0000
Resent-Message-ID: <handler.66912.B66912.173107336028221 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173107336028221
          (code B ref 66912); Fri, 08 Nov 2024 13:43:02 +0000
Received: (at 66912) by debbugs.gnu.org; 8 Nov 2024 13:42:40 +0000
Received: from localhost ([127.0.0.1]:51559 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t9PG3-0007L6-H2
	for submit <at> debbugs.gnu.org; Fri, 08 Nov 2024 08:42:39 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44494)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t9PG1-0007Kr-FB
 for 66912 <at> debbugs.gnu.org; Fri, 08 Nov 2024 08:42:38 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 91F191004A1;
 Fri,  8 Nov 2024 08:42:30 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1731073349;
 bh=PRgbSnuJpoI80lfbUILP/e9WIamgo/mI1pZJwMextDA=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=ou3KW5Xr0R4QwpWFht1JeeRLsl3Wy0ex3L97SnhFyF1aAqhyl17/HQAxNpvpYxJqb
 w04bL7X9F9g/FmKAfb6ojPRsyK/pkbfjfKshFEI1pfZDBABH7QpSPI5vLwbMdtV0tA
 W3xbEXVNyYyXMup+HTgmr7Cu66Hmf2z/90MgMGwBkTUtTJKToML5Z6uj1lGQ3Q/VcI
 6AdQgm5NKzvVsDSMfx0zm8u4leDFKIDur0jlyco3FwgUhUHTHl7BSX5zTnCKhi320s
 6XE/YxjpCou+TEpAb4u4blvQjzwuZYNwU+YLkzDU5mO1GzWc7bammAos6TBKEe5Sj6
 DJ5DWz2XBfciQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D08201001D9;
 Fri,  8 Nov 2024 08:42:29 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A092712032C;
 Fri,  8 Nov 2024 08:42:29 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <Zyz1xWXcfEghUWOa@HIDDEN> (Alan Mackenzie's message of
 "Thu, 7 Nov 2024 17:15:49 +0000")
Message-ID: <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
References: <ZyoxoMo8u23e_aHD@HIDDEN>
 <jwvh68lwm8w.fsf-monnier+emacs@HIDDEN>
 <ZyqBE6HALcSno8g0@HIDDEN>
 <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
 <ZyuYGd1IBLu4el5d@HIDDEN>
 <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
 <ZyvNu25qkpBvGa47@HIDDEN>
 <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
 <Zyy0pB9a-6Bx_uDx@HIDDEN>
 <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
 <Zyz1xWXcfEghUWOa@HIDDEN>
Date: Fri, 08 Nov 2024 08:42:29 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.067 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> 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 understand that, but I don't think it explains why you think it's
a problem.  E.g. when you're in the debugger, you can see the stack
trace which tells you we're loading A, so you don't need to be told
"while loading A" in the error message.

>> > 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!

I'm just describing the way I see it: I personally don't have a good
intuition of how/when it could misbehave nor how to work around such
cases, whereas I very much do for the approach I propose and AFAICT it's
not just because I proposed it but it's because it follows
a known pattern, so I expect the same will hold for other coders.

Of course it wouldn't be the first time I'd be wrong.  Also, I didn't
say I objected to your approach, I just have a different preference: you
don't have to convince me.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 08 Nov 2024 20:03:02 +0000
Resent-Message-ID: <handler.66912.B66912.173109612629816 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173109612629816
          (code B ref 66912); Fri, 08 Nov 2024 20:03:02 +0000
Received: (at 66912) by debbugs.gnu.org; 8 Nov 2024 20:02:06 +0000
Received: from localhost ([127.0.0.1]:52238 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t9VBF-0007kq-KB
	for submit <at> debbugs.gnu.org; Fri, 08 Nov 2024 15:02:05 -0500
Received: from mail.muc.de ([193.149.48.3]:45772)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t9VBC-0007k2-5G
 for 66912 <at> debbugs.gnu.org; Fri, 08 Nov 2024 15:02:04 -0500
Received: (qmail 6579 invoked by uid 3782); 8 Nov 2024 21:01:55 +0100
Received: from muc.de (p4fe150f0.dip0.t-ipconnect.de [79.225.80.240]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Fri, 08 Nov 2024 21:01:55 +0100
Received: (qmail 12355 invoked by uid 1000); 8 Nov 2024 20:01:54 -0000
Date: Fri, 8 Nov 2024 20:01:54 +0000
Message-ID: <Zy5uMii0Fw-sz_MW@HIDDEN>
References: <ZyqBE6HALcSno8g0@HIDDEN>
 <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
 <ZyuYGd1IBLu4el5d@HIDDEN>
 <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
 <ZyvNu25qkpBvGa47@HIDDEN>
 <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
 <Zyy0pB9a-6Bx_uDx@HIDDEN>
 <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
 <Zyz1xWXcfEghUWOa@HIDDEN>
 <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Fri, Nov 08, 2024 at 08:42:29 -0500, Stefan Monnier wrote:
> > 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 understand that, but I don't think it explains why you think it's
> a problem.  E.g. when you're in the debugger, you can see the stack
> trace which tells you we're loading A, so you don't need to be told
> "while loading A" in the error message.

OK, I see what you mean.  I took it for granted that the message should
be the same, regardless of whether it is reported by a debugger or by
the error handler.  You're suggesting that's not really necessary.

There may be some way the message might be output by a handler-bind
handler before the stack gets unwound, but which doesn't end up with a
debugger backtrace.  I haven't really thought that through yet.

Even when the information is in a debugger backtrace, I think there
would be merit in outputting "While loading foo.el... " as part of the
error message.  In the backtrace, the succession of entries for Fload is
going to be dispersed and not all that easy to trace, but is likely to
be one of the first things the person debugging will want to see.

> >> > 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!

> I'm just describing the way I see it: I personally don't have a good
> intuition of how/when it could misbehave nor how to work around such
> cases, whereas I very much do for the approach I propose and AFAICT it's
> not just because I proposed it but it's because it follows
> a known pattern, so I expect the same will hold for other coders.

Experience with byte-compile-form-stack suggests it won't misbehave.
It's simplicity should make it easy to think through.

> Of course it wouldn't be the first time I'd be wrong.  Also, I didn't
> say I objected to your approach, I just have a different preference: you
> don't have to convince me.

In the approach where we copy Vloads_in_progress inside signal_or_quit,
we still don't have a reliable way of preventing the "While loading
foo.el... " from getting into other messages where it doesn't belong,
like "end of screen".  You've suggested taking the difference between
Vloads_in_progress at two stages of the error handling.  I'll admit I
haven't tried that out yet, but it feels to me complicated and fragile.

It feels we've lost momentum for this fix.  I still favour my current
version of the patch, which works, and I think is simpler than the
alternative approach.

It would be nice to get this finalised and committed.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 08 Nov 2024 20:28:01 +0000
Resent-Message-ID: <handler.66912.B66912.17310976233230 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17310976233230
          (code B ref 66912); Fri, 08 Nov 2024 20:28:01 +0000
Received: (at 66912) by debbugs.gnu.org; 8 Nov 2024 20:27:03 +0000
Received: from localhost ([127.0.0.1]:52285 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t9VZP-0000q2-Bh
	for submit <at> debbugs.gnu.org; Fri, 08 Nov 2024 15:27:03 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57707)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t9VZM-0000pV-57
 for 66912 <at> debbugs.gnu.org; Fri, 08 Nov 2024 15:27:01 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C8662444651;
 Fri,  8 Nov 2024 15:26:52 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1731097611;
 bh=jcbD0Rn/py335Lfptb0jXeFft+ybJhuXQ9kSG7UITeU=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=fUZi7uroOPUqu5360oQ7caa6o/vEmoxWlioJro6XgaKULLmMcUyrC+QxKxeW3xtPG
 cNX1TKwRMkZ2qUuB+Web1Cp4yl7CMd+LRyIFNEZVP/oGMGhDShhs2P6sZAuMaMs9WS
 pn1jUKROe5fNWdBq/nCoqDCMM35Ja5IADEvETqIEgNqORB/FrY/JzbdByo54t7FA3R
 IHrbuo7TOMgYpcm0UEg8p+puLU+/tdI/0mAc7z7mu755nYf8Q1YHXPCWnDWs3wWbSr
 bPJgT2jF7dYY6ScSkzChHCA/c0vC6D5XZLDmvXpGqg2I/N9O8jdTklVrs9Tz2zXa/E
 YbyxWkWJTpbnw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 96B1944464D;
 Fri,  8 Nov 2024 15:26:51 -0500 (EST)
Received: from asado (bras-base-mtrlpq0776w-grc-08-184-145-223-228.dsl.bell.ca
 [184.145.223.228])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 84FF61200C7;
 Fri,  8 Nov 2024 15:26:51 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <Zy5uMii0Fw-sz_MW@HIDDEN> (Alan Mackenzie's message of
 "Fri, 8 Nov 2024 20:01:54 +0000")
Message-ID: <jwvr07lo4y3.fsf-monnier+emacs@HIDDEN>
References: <ZyqBE6HALcSno8g0@HIDDEN>
 <jwvttcluyki.fsf-monnier+emacs@HIDDEN>
 <ZyuYGd1IBLu4el5d@HIDDEN>
 <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
 <ZyvNu25qkpBvGa47@HIDDEN>
 <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
 <Zyy0pB9a-6Bx_uDx@HIDDEN>
 <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
 <Zyz1xWXcfEghUWOa@HIDDEN>
 <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
 <Zy5uMii0Fw-sz_MW@HIDDEN>
Date: Fri, 08 Nov 2024 15:26:51 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.135 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I understand that, but I don't think it explains why you think it's
>> a problem.  E.g. when you're in the debugger, you can see the stack
>> trace which tells you we're loading A, so you don't need to be told
>> "while loading A" in the error message.
> OK, I see what you mean.  I took it for granted that the message should
> be the same, regardless of whether it is reported by a debugger or by
> the error handler.

AFAIK the debugger does not emit the "error message" at all, it shows
the error object instead, so it's already different.

And the full info would readily be available from `Vloads_in_progress_at_error`.

>> I'm just describing the way I see it: I personally don't have a good
>> intuition of how/when it could misbehave nor how to work around such
>> cases, whereas I very much do for the approach I propose and AFAICT it's
>> not just because I proposed it but it's because it follows
>> a known pattern, so I expect the same will hold for other coders.
> Experience with byte-compile-form-stack suggests it won't misbehave.
> Its simplicity should make it easy to think through.

AFAICT

    (equal (error-message-string ERROR-OBJECT)
           (error-message-string ERROR-OBJECT))

will not always return t, which I'd consider as a misbehavior.

I don't mean that we need to fix it.  Just that that there *will* be
misbehaviors, because we use a low-tech approach which stashes the info
in a global variable.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 09 Nov 2024 12:36:01 +0000
Resent-Message-ID: <handler.66912.B66912.17311557297484 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17311557297484
          (code B ref 66912); Sat, 09 Nov 2024 12:36:01 +0000
Received: (at 66912) by debbugs.gnu.org; 9 Nov 2024 12:35:29 +0000
Received: from localhost ([127.0.0.1]:53802 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t9kgb-0001we-9X
	for submit <at> debbugs.gnu.org; Sat, 09 Nov 2024 07:35:29 -0500
Received: from mail.muc.de ([193.149.48.3]:52651)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1t9kgY-0001w6-Vo
 for 66912 <at> debbugs.gnu.org; Sat, 09 Nov 2024 07:35:27 -0500
Received: (qmail 46884 invoked by uid 3782); 9 Nov 2024 13:35:20 +0100
Received: from muc.de (pd953a3cb.dip0.t-ipconnect.de [217.83.163.203]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Sat, 09 Nov 2024 13:35:20 +0100
Received: (qmail 9954 invoked by uid 1000); 9 Nov 2024 12:35:19 -0000
Date: Sat, 9 Nov 2024 12:35:19 +0000
Message-ID: <Zy9XB1TaxjBSQ1im@HIDDEN>
References: <ZyuYGd1IBLu4el5d@HIDDEN>
 <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
 <ZyvNu25qkpBvGa47@HIDDEN>
 <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
 <Zyy0pB9a-6Bx_uDx@HIDDEN>
 <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
 <Zyz1xWXcfEghUWOa@HIDDEN>
 <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
 <Zy5uMii0Fw-sz_MW@HIDDEN>
 <jwvr07lo4y3.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvr07lo4y3.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Fri, Nov 08, 2024 at 15:26:51 -0500, Stefan Monnier wrote:
> >> I understand that, but I don't think it explains why you think it's
> >> a problem.  E.g. when you're in the debugger, you can see the stack
> >> trace which tells you we're loading A, so you don't need to be told
> >> "while loading A" in the error message.
> > OK, I see what you mean.  I took it for granted that the message should
> > be the same, regardless of whether it is reported by a debugger or by
> > the error handler.

> AFAIK the debugger does not emit the "error message" at all, it shows
> the error object instead, so it's already different.

That doesn't seem to address the point I made above at all.

> And the full info would readily be available from `Vloads_in_progress_at_error`.

Vloads_in_progress_at_error is not available to the user, being an
internal variable.

The problem with the Vloads_in_progress_at_error approach is that its
information gets prefixed to EVERY error message which occurs while the
debugger's recursive edit is in progress.  This is not a Good Thing.
The methods suggested so far to fix this don't as yet seem satisfactory,
and we don't seem to be progressing on this front.

> >> I'm just describing the way I see it: I personally don't have a good
> >> intuition of how/when it could misbehave nor how to work around such
> >> cases, whereas I very much do for the approach I propose and AFAICT it's
> >> not just because I proposed it but it's because it follows
> >> a known pattern, so I expect the same will hold for other coders.
> > Experience with byte-compile-form-stack suggests it won't misbehave.
> > Its simplicity should make it easy to think through.

> AFAICT

>     (equal (error-message-string ERROR-OBJECT)
>            (error-message-string ERROR-OBJECT))

> will not always return t, which I'd consider as a misbehavior.

No.  The proposed mechanism of Vloads_still_in_progress has no influence
on error-message-string.

> I don't mean that we need to fix it.  Just that that there *will* be
> misbehaviors, because we use a low-tech approach which stashes the info
> in a global variable.

It may be low tech, but it's effective.  Its simplicity makes
misbehaviour unlikely.  We didn't see any (that I know of) with
byte-compile-form-stack.

Can we get this bug closed soon, please?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 09 Nov 2024 16:46:02 +0000
Resent-Message-ID: <handler.66912.B66912.173117074817734 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173117074817734
          (code B ref 66912); Sat, 09 Nov 2024 16:46:02 +0000
Received: (at 66912) by debbugs.gnu.org; 9 Nov 2024 16:45:48 +0000
Received: from localhost ([127.0.0.1]:54256 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t9oaq-0004by-BP
	for submit <at> debbugs.gnu.org; Sat, 09 Nov 2024 11:45:48 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19178)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1t9oal-0004bQ-MZ
 for 66912 <at> debbugs.gnu.org; Sat, 09 Nov 2024 11:45:44 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 078BD801F1;
 Sat,  9 Nov 2024 11:45:38 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1731170737;
 bh=zJbNbZGtdl0aoI/IesL9pV78HyyX4cyHSWgM9KemMig=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=AFXiipeRAbXvTcNBz8O1UUGOLyue9SN2Cd1vNwURoGFtIiQDySWs6D7QD3PgywHzz
 EFwvMinqoK/7UG+qz150jEfmmZgCGIchrzKybTVrecDGYJwTe+sHZPcH0gY/sDzjvy
 G6MUV7r5WJvhvwCJSNKQyv8QVjb2NzQGtMxtX/1hgSoD+Tl7iWqTZvDy35OrTHyDGj
 vT+fruFxd9UlkpqUZvVvjW4iIelFz2eZhdyv4N6iCVHSPrw8y/SB6FsDuVs0UlXL0F
 qPxFzllMk9nR56yiiXGn/LLTQg4ybKw8Pm1ae6stWCWEOwtb8FhaE/GjqbJWkBpcz5
 XwyvhH760A2+w==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1D900803AD;
 Sat,  9 Nov 2024 11:45:37 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E63CF120401;
 Sat,  9 Nov 2024 11:45:36 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <Zy9XB1TaxjBSQ1im@HIDDEN> (Alan Mackenzie's message of
 "Sat, 9 Nov 2024 12:35:19 +0000")
Message-ID: <jwv8qtsz7wc.fsf-monnier+emacs@HIDDEN>
References: <ZyuYGd1IBLu4el5d@HIDDEN>
 <jwva5ecuxop.fsf-monnier+emacs@HIDDEN>
 <ZyvNu25qkpBvGa47@HIDDEN>
 <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
 <Zyy0pB9a-6Bx_uDx@HIDDEN>
 <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
 <Zyz1xWXcfEghUWOa@HIDDEN>
 <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
 <Zy5uMii0Fw-sz_MW@HIDDEN>
 <jwvr07lo4y3.fsf-monnier+emacs@HIDDEN>
 <Zy9XB1TaxjBSQ1im@HIDDEN>
Date: Sat, 09 Nov 2024 11:45:36 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.040 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> > OK, I see what you mean.  I took it for granted that the message should
>> > be the same, regardless of whether it is reported by a debugger or by
>> > the error handler.
>> AFAIK the debugger does not emit the "error message" at all, it shows
>> the error object instead, so it's already different.
> That doesn't seem to address the point I made above at all.

Then I don't know what "the message" you're referring to.
(or are you referring to some other point you made elsewhere?)

>> And the full info would readily be available from `Vloads_in_progress_at_error`.
> Vloads_in_progress_at_error is not available to the user, being an
> internal variable.

[ I'd make it user-visible, as well Vload_in_progress, but that's not
  actually relevant.  ]

Even if it's not directly exposed to the user the info *is* available,
so we can offer ways to make use of it.

> The problem with the Vloads_in_progress_at_error approach is that its
> information gets prefixed to EVERY error message which occurs while the
> debugger's recursive edit is in progress.  This is not a Good Thing.

If `load-in-progress-at-error` hold (C B A), I'd make the error message
emit either nothing, or just C, or B and C, or A and B and C depending
on where in the call stack we're calling from (using the `while` loop
that compares to `load-in-progress`).

From within the debugger, presumably `load-in-progress` would still be
(C B A), so error messages would usually display no "while loading" at
all, unless the errors themselves occur within a load of some file D,
of course.

Note that this is not just the behavior we happen to get with the hacks
I came upon along the way.  It's the behavior I'm aiming for (e.g. it's
also the behavior that we'd get with the `handler-bind` approach
I advocated earlier).

>> AFAICT
>
>>     (equal (error-message-string ERROR-OBJECT)
>>            (error-message-string ERROR-OBJECT))
>
>> will not always return t, which I'd consider as a misbehavior.
>
> No.  The proposed mechanism of Vloads_still_in_progress has no influence
> on error-message-string.

Sorry, I meant

    (equal (prefix-load-file-names
            (error-message-string ERROR-OBJECT))
           (prefix-load-file-names
            (error-message-string ERROR-OBJECT)))

[ I assumed you had added a call to `prefix-load-file-names` in
  `error-message-string`.  Not sure why you didn't, but I haven't
  thought very much about which option is best in this regard.  ]

> Can we get this bug closed soon, please?

As I said, you don't need to convince me.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 10 Nov 2024 10:41:01 +0000
Resent-Message-ID: <handler.66912.B66912.173123524210961 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173123524210961
          (code B ref 66912); Sun, 10 Nov 2024 10:41:01 +0000
Received: (at 66912) by debbugs.gnu.org; 10 Nov 2024 10:40:42 +0000
Received: from localhost ([127.0.0.1]:55849 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tA5N3-0002qi-IE
	for submit <at> debbugs.gnu.org; Sun, 10 Nov 2024 05:40:41 -0500
Received: from mail.muc.de ([193.149.48.3]:35426)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1tA5N0-0002qO-J0
 for 66912 <at> debbugs.gnu.org; Sun, 10 Nov 2024 05:40:39 -0500
Received: (qmail 72809 invoked by uid 3782); 10 Nov 2024 11:40:32 +0100
Received: from muc.de (pd953a71d.dip0.t-ipconnect.de [217.83.167.29]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Sun, 10 Nov 2024 11:40:32 +0100
Received: (qmail 4193 invoked by uid 1000); 10 Nov 2024 10:40:31 -0000
Date: Sun, 10 Nov 2024 10:40:31 +0000
Message-ID: <ZzCNn0nMmXuBqgpA@HIDDEN>
References: <ZyvNu25qkpBvGa47@HIDDEN>
 <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
 <Zyy0pB9a-6Bx_uDx@HIDDEN>
 <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
 <Zyz1xWXcfEghUWOa@HIDDEN>
 <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
 <Zy5uMii0Fw-sz_MW@HIDDEN>
 <jwvr07lo4y3.fsf-monnier+emacs@HIDDEN>
 <Zy9XB1TaxjBSQ1im@HIDDEN>
 <jwv8qtsz7wc.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwv8qtsz7wc.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Sat, Nov 09, 2024 at 11:45:36 -0500, Stefan Monnier wrote:
> >> > OK, I see what you mean.  I took it for granted that the message should
> >> > be the same, regardless of whether it is reported by a debugger or by
> >> > the error handler.
> >> AFAIK the debugger does not emit the "error message" at all, it shows
> >> the error object instead, so it's already different.
> > That doesn't seem to address the point I made above at all.

> Then I don't know what "the message" you're referring to.
> (or are you referring to some other point you made elsewhere?)

I simply meant what the user sees on the screen.  If the user sees
"While loading foo.el... \nWrong type argument: listp, baz" whilst doing
something, then enables the debugger and repeats the action, she should
see the same message at the top of the backtrace.  Surely?  Truncating
that message can only lead to confusion.

> >> And the full info would readily be available from `Vloads_in_progress_at_error`.
> > Vloads_in_progress_at_error is not available to the user, being an
> > internal variable.

> [ I'd make it user-visible, as well Vload_in_progress, but that's not
>   actually relevant.  ]

> Even if it's not directly exposed to the user the info *is* available,
> so we can offer ways to make use of it.

I am proposing a single way.

> > The problem with the Vloads_in_progress_at_error approach is that its
> > information gets prefixed to EVERY error message which occurs while the
> > debugger's recursive edit is in progress.  This is not a Good Thing.

> If `load-in-progress-at-error` hold (C B A), I'd make the error message
> emit either nothing, or just C, or B and C, or A and B and C depending
> on where in the call stack we're calling from (using the `while` loop
> that compares to `load-in-progress`).

> >From within the debugger, presumably `load-in-progress` would still be
> (C B A), so error messages would usually display no "while loading" at
> all, unless the errors themselves occur within a load of some file D,
> of course.

> Note that this is not just the behavior we happen to get with the hacks
> I came upon along the way.  It's the behavior I'm aiming for (e.g. it's
> also the behavior that we'd get with the `handler-bind` approach
> I advocated earlier).

I'll go back and see if I can find that.

Again, why do you think this is what we should aim for, rather than
having the same message in the error handler and at the top of a
backtrace?

[ .... ]

> Sorry, I meant

>     (equal (prefix-load-file-names
>             (error-message-string ERROR-OBJECT))
>            (prefix-load-file-names
>             (error-message-string ERROR-OBJECT)))

OK, that would indeed return nil if the first call to p-l-f-names was
the first such call since the error occurred.

> [ I assumed you had added a call to `prefix-load-file-names` in
>   `error-message-string`.  Not sure why you didn't, but I haven't
>   thought very much about which option is best in this regard.  ]

I wasn't actually aware of the function error-message-string.  Seeing as
how it is called from many places (over 100), there doesn't seem to be
any advantage in putting a call to prefix-load-file-names inside it.

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 10 Nov 2024 16:47:02 +0000
Resent-Message-ID: <handler.66912.B66912.17312571638835 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.17312571638835
          (code B ref 66912); Sun, 10 Nov 2024 16:47:02 +0000
Received: (at 66912) by debbugs.gnu.org; 10 Nov 2024 16:46:03 +0000
Received: from localhost ([127.0.0.1]:56410 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tAB4d-0002IR-0d
	for submit <at> debbugs.gnu.org; Sun, 10 Nov 2024 11:46:03 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62302)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1tAB4a-0002Hp-Qq
 for 66912 <at> debbugs.gnu.org; Sun, 10 Nov 2024 11:46:01 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4A5724409A4;
 Sun, 10 Nov 2024 11:45:54 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1731257149;
 bh=/HWhDLoPaBOzlRN2fFu21bm9XqZ8B52+DHaQhGRJn6M=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=RS6yxuoWHTUwgTIVfjOJM7WzmbYgHHTu3lVhWm/1heZdN1F0uH2dCQWoZBRrBK1Fj
 Gvs8oLA949XzIFOA+O6bSlgbh5DKhZy4da7tTWr83iZNbVccKcw9SdH0g+uZOaX0av
 4V69hbR/Y6oAV4O3C5/E92HNDCxyRIWcWOeWK8IO7Qb+JMi2xQJ3N2suDDr/kYD988
 M90IPVNkEWhuQQNzOOQQveZnwYKiRaPKE+3/SJJiHCKywcue0CxeaBefcZTglMAYjc
 kgYpIzg55HWTB1QTtUMNPTpQSumbAzYrLzskujps/8O3mJZokHZ6FX9ThcBayxfc61
 jw6OwCu/re6Eg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 188F64409C8;
 Sun, 10 Nov 2024 11:45:49 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E16E81204E5;
 Sun, 10 Nov 2024 11:45:48 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZzCNn0nMmXuBqgpA@HIDDEN> (Alan Mackenzie's message of
 "Sun, 10 Nov 2024 10:40:31 +0000")
Message-ID: <jwv7c9bxd41.fsf-monnier+emacs@HIDDEN>
References: <ZyvNu25qkpBvGa47@HIDDEN>
 <jwvmsict1i0.fsf-monnier+emacs@HIDDEN>
 <Zyy0pB9a-6Bx_uDx@HIDDEN>
 <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
 <Zyz1xWXcfEghUWOa@HIDDEN>
 <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
 <Zy5uMii0Fw-sz_MW@HIDDEN>
 <jwvr07lo4y3.fsf-monnier+emacs@HIDDEN>
 <Zy9XB1TaxjBSQ1im@HIDDEN>
 <jwv8qtsz7wc.fsf-monnier+emacs@HIDDEN>
 <ZzCNn0nMmXuBqgpA@HIDDEN>
Date: Sun, 10 Nov 2024 11:45:38 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.040 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> Then I don't know what "the message" you're referring to.
>> (or are you referring to some other point you made elsewhere?)
> I simply meant what the user sees on the screen.  If the user sees
> "While loading foo.el... \nWrong type argument: listp, baz" whilst doing
> something, then enables the debugger and repeats the action, she should
> see the same message at the top of the backtrace.  Surely?  Truncating
> that message can only lead to confusion.

I still don't understand: currently, if you see a message "Wrong
type argument: listp, baz", then enable the debugger and reproduce the
error, you won't see "Wrong type argument: listp, baz" but

    Debugger entered--Lisp error: (wrong-type-argument listp baz)

instead.  IOW, instead of the error message, you see the error object.

> Again, why do you think this is what we should aim for, rather than
> having the same message in the error handler and at the top of a
> backtrace?

Because of my "A => B => compile => C => D" example: the message I want
to have depends on the chain from the point where I catch the error
(i.e. the `condition-case`) to the point where the error is signaled.
And I don't really care about the debugger case.

        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 10 Nov 2024 17:49:02 +0000
Resent-Message-ID: <handler.66912.B66912.173126090919782 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173126090919782
          (code B ref 66912); Sun, 10 Nov 2024 17:49:02 +0000
Received: (at 66912) by debbugs.gnu.org; 10 Nov 2024 17:48:29 +0000
Received: from localhost ([127.0.0.1]:56509 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tAC33-000590-HW
	for submit <at> debbugs.gnu.org; Sun, 10 Nov 2024 12:48:29 -0500
Received: from mail.muc.de ([193.149.48.3]:25824)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1tAC30-00058l-Q5
 for 66912 <at> debbugs.gnu.org; Sun, 10 Nov 2024 12:48:27 -0500
Received: (qmail 56623 invoked by uid 3782); 10 Nov 2024 18:48:20 +0100
Received: from muc.de (pd953a71d.dip0.t-ipconnect.de [217.83.167.29]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Sun, 10 Nov 2024 18:48:20 +0100
Received: (qmail 21498 invoked by uid 1000); 10 Nov 2024 17:48:19 -0000
Date: Sun, 10 Nov 2024 17:48:19 +0000
Message-ID: <ZzDx4wbwZwwtH3Ew@HIDDEN>
References: <Zyy0pB9a-6Bx_uDx@HIDDEN>
 <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
 <Zyz1xWXcfEghUWOa@HIDDEN>
 <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
 <Zy5uMii0Fw-sz_MW@HIDDEN>
 <jwvr07lo4y3.fsf-monnier+emacs@HIDDEN>
 <Zy9XB1TaxjBSQ1im@HIDDEN>
 <jwv8qtsz7wc.fsf-monnier+emacs@HIDDEN>
 <ZzCNn0nMmXuBqgpA@HIDDEN>
 <jwv7c9bxd41.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwv7c9bxd41.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Sun, Nov 10, 2024 at 11:45:38 -0500, Stefan Monnier wrote:
> >> Then I don't know what "the message" you're referring to.
> >> (or are you referring to some other point you made elsewhere?)
> > I simply meant what the user sees on the screen.  If the user sees
> > "While loading foo.el... \nWrong type argument: listp, baz" whilst doing
> > something, then enables the debugger and repeats the action, she should
> > see the same message at the top of the backtrace.  Surely?  Truncating
> > that message can only lead to confusion.

> I still don't understand: currently, if you see a message "Wrong
> type argument: listp, baz", then enable the debugger and reproduce the
> error, you won't see "Wrong type argument: listp, baz" but

>     Debugger entered--Lisp error: (wrong-type-argument listp baz)

> instead.  IOW, instead of the error message, you see the error object.

I've never noticed these to be different.  I suspect most users wouldn't
either.  I wasn't talking about the boilerplate and formatting being
different, I was talking about the essence of the message, the
substance.  It is the same in the two examples you have given.

Part of that essence is to be the "While loading foo.el... " bit.  I
think the user should see that, both when the error first occurs, and
when it occurs again after enabling debug-on-error and repeating the
action that caused it.

> > Again, why do you think this is what we should aim for, rather than
> > having the same message in the error handler and at the top of a
> > backtrace?

> Because of my "A => B => compile => C => D" example: the message I want
> to have depends on the chain from the point where I catch the error
> (i.e. the `condition-case`) to the point where the error is signaled.
> And I don't really care about the debugger case.

That is no explanation as to WHY you think it's the right thing.  The
point in that chain where we catch the error is an internal
implementation detail, of no interest to the user.  WHY are you so
unconcerned about the debugger case?  I think it would be consistent to
display "While loading..." the same in both cases.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 10 Nov 2024 21:38:02 +0000
Resent-Message-ID: <handler.66912.B66912.173127465927696 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173127465927696
          (code B ref 66912); Sun, 10 Nov 2024 21:38:02 +0000
Received: (at 66912) by debbugs.gnu.org; 10 Nov 2024 21:37:39 +0000
Received: from localhost ([127.0.0.1]:56892 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tAFco-0007Cd-O7
	for submit <at> debbugs.gnu.org; Sun, 10 Nov 2024 16:37:39 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9474)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1tAFcl-0007CL-VI
 for 66912 <at> debbugs.gnu.org; Sun, 10 Nov 2024 16:37:37 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D41E4442AEE;
 Sun, 10 Nov 2024 16:37:29 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1731274648;
 bh=4WHnRTiETC8DifNvtev8eScoY+k8ZIICKzo2gP+g1yE=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=b5Mlt7+5WxHypk7tMuyrDgprhath2cfRNfU06Az9IJyrCfh9K5Q130DPjIsquWm7L
 ELi0yUu9TVBOxYlI29C4pDuteJugqqGXWPomGIbe49QO8GNsMVQ+W0IUaPSyxIKq4+
 FYjcjgdmVdDknlGVtzsWE2ZeWv+uqcxEBjSUpPurqudxhrwpz0vxPI2/bDVGvyf4Mr
 b40d1lvATyuJtlbJ23JVl3vJSduUuvPLLhSWeczWI38znZmQVdmjmyQ7eqWdjW3NDE
 IXvjrCRT1kzxrIpKZSKzciRpQ40buyxU5zw0SG0OYy4JBoKKYJ65kqhKd0eTHFBYu/
 9RlQslrWpsXdw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C00DF442AE3;
 Sun, 10 Nov 2024 16:37:28 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 94DB8120426;
 Sun, 10 Nov 2024 16:37:28 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZzDx4wbwZwwtH3Ew@HIDDEN> (Alan Mackenzie's message of
 "Sun, 10 Nov 2024 17:48:19 +0000")
Message-ID: <jwv8qtqwzcn.fsf-monnier+emacs@HIDDEN>
References: <Zyy0pB9a-6Bx_uDx@HIDDEN>
 <jwvzfmbrpzx.fsf-monnier+emacs@HIDDEN>
 <Zyz1xWXcfEghUWOa@HIDDEN>
 <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
 <Zy5uMii0Fw-sz_MW@HIDDEN>
 <jwvr07lo4y3.fsf-monnier+emacs@HIDDEN>
 <Zy9XB1TaxjBSQ1im@HIDDEN>
 <jwv8qtsz7wc.fsf-monnier+emacs@HIDDEN>
 <ZzCNn0nMmXuBqgpA@HIDDEN>
 <jwv7c9bxd41.fsf-monnier+emacs@HIDDEN>
 <ZzDx4wbwZwwtH3Ew@HIDDEN>
Date: Sun, 10 Nov 2024 16:37:26 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.040 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> Because of my "A => B => compile => C => D" example: the message I want
>> to have depends on the chain from the point where I catch the error
>> (i.e. the `condition-case`) to the point where the error is signaled.
>> And I don't really care about the debugger case.
> That is no explanation as to WHY you think it's the right thing.
> The point in that chain where we catch the error is an internal
> implementation detail, of no interest to the user.

Not at all.  In the above example, the error message goes to the
compilation buffer, and it would be weird for that buffer to say "while
loading A while loading B" whereas the compiled code loads neither.

> WHY are you so unconcerned about the debugger case?

In the debugger case, I usually have direct access to the problematic
code and usually don't care that much about the further parts of the
context explaining why that code is executed.
Occasionally I do, but "loading" is not special in this respect: I will
just as often be interested to know which command was used, in which
buffer, or which hook caused that code to be run.

> I think it would be consistent to display "While loading..." the same
> in both cases.

To be honest, I don't see much value in displaying "while loading" in
the echo area in general.  I'm not opposed to it, but the only case
where I know it could be helpful is during compilation (which I'm
mostly interested to see it in the compilation buffer).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 12 Nov 2024 14:55:01 +0000
Resent-Message-ID: <handler.66912.B66912.173142324611269 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173142324611269
          (code B ref 66912); Tue, 12 Nov 2024 14:55:01 +0000
Received: (at 66912) by debbugs.gnu.org; 12 Nov 2024 14:54:06 +0000
Received: from localhost ([127.0.0.1]:33071 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tAsHO-0002vg-D2
	for submit <at> debbugs.gnu.org; Tue, 12 Nov 2024 09:54:06 -0500
Received: from mail.muc.de ([193.149.48.3]:44827)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1tAsHM-0002v9-Pj
 for 66912 <at> debbugs.gnu.org; Tue, 12 Nov 2024 09:54:05 -0500
Received: (qmail 36608 invoked by uid 3782); 12 Nov 2024 15:53:57 +0100
Received: from muc.de (p4fe15556.dip0.t-ipconnect.de [79.225.85.86]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Tue, 12 Nov 2024 15:53:57 +0100
Received: (qmail 10368 invoked by uid 1000); 12 Nov 2024 14:53:56 -0000
Date: Tue, 12 Nov 2024 14:53:56 +0000
Message-ID: <ZzNsBGpp-AZLSQaU@HIDDEN>
References: <Zyz1xWXcfEghUWOa@HIDDEN>
 <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
 <Zy5uMii0Fw-sz_MW@HIDDEN>
 <jwvr07lo4y3.fsf-monnier+emacs@HIDDEN>
 <Zy9XB1TaxjBSQ1im@HIDDEN>
 <jwv8qtsz7wc.fsf-monnier+emacs@HIDDEN>
 <ZzCNn0nMmXuBqgpA@HIDDEN>
 <jwv7c9bxd41.fsf-monnier+emacs@HIDDEN>
 <ZzDx4wbwZwwtH3Ew@HIDDEN>
 <jwv8qtqwzcn.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwv8qtqwzcn.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Sun, Nov 10, 2024 at 16:37:26 -0500, Stefan Monnier wrote:
> >> Because of my "A => B => compile => C => D" example: the message I want
> >> to have depends on the chain from the point where I catch the error
> >> (i.e. the `condition-case`) to the point where the error is signaled.
> >> And I don't really care about the debugger case.
> > That is no explanation as to WHY you think it's the right thing.
> > The point in that chain where we catch the error is an internal
> > implementation detail, of no interest to the user.

> Not at all.  In the above example, the error message goes to the
> compilation buffer, and it would be weird for that buffer to say "while
> loading A while loading B" whereas the compiled code loads neither.

OK, so you were using "the point in the chain where we catch the error",
which is of no interest to the user, as a proxy for how and where an
error message gets displayed.

I thought we were agreed that the "A => B => compile => C => D" was
vanishingly rare and probably doesn't occur at all in the Emacs sources.
In that case, why are you giving it priority over the other concerns
(such as consistency of messages displayed to the user) that I have
raised?

> > WHY are you so unconcerned about the debugger case?

> In the debugger case, I usually have direct access to the problematic
> code and usually don't care that much about the further parts of the
> context explaining why that code is executed.

But other users might like to see this information.  I certainly would.
The stack of files being loaded is likely to be of interest.  Even you
imply you would sometimes like to see it.

Would you please clarify whether you are opposed to outputting the
information (about the stack of files being loaded) in the debugger
case, or are merely indifferent about it.  If the former, I still don't
understand why; I would still appreciate justification.

> Occasionally I do, but "loading" is not special in this respect: I will
> just as often be interested to know which command was used, in which
> buffer, or which hook caused that code to be run.

It is true that Emacs error messages are typically poor in the extreme,
in that they fail to identify the pertinent command, buffer, hook, or
variable.  I have been trying to improve this for several years, with
mixed success.  The thing about loading is that it is frequently
recursive, typically by the function `require'.  Being told which file
the failing Lisp came from is as good as saying which buffer, and likely
better in batch mode.

> > I think it would be consistent to display "While loading..." the same
> > in both cases.

> To be honest, I don't see much value in displaying "while loading" in
> the echo area in general.

To be frank, displaying nothing but

    Wrong type argument: integer-or-marker-p, nil

to the user is insulting.  It is nearly content-free, giving the user no
clue as to where to start looking for the error.  It implies that the
users' time is less important than that of Emacs developers, who have
failed to implement proper error handling.

Informing the user which file the error occurred in, though far from
ideal, is significantly better than not doing so.

> I'm not opposed to it, but the only case where I know it could be
> helpful is during compilation (which I'm mostly interested to see it
> in the compilation buffer).

In this case, the error message is indeed displayed in *Compile-Log*.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 12 Nov 2024 15:40:01 +0000
Resent-Message-ID: <handler.66912.B66912.173142594324459 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66912
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 66912 <at> debbugs.gnu.org
Received: via spool by 66912-submit <at> debbugs.gnu.org id=B66912.173142594324459
          (code B ref 66912); Tue, 12 Nov 2024 15:40:01 +0000
Received: (at 66912) by debbugs.gnu.org; 12 Nov 2024 15:39:03 +0000
Received: from localhost ([127.0.0.1]:38943 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tAsys-0006MH-JX
	for submit <at> debbugs.gnu.org; Tue, 12 Nov 2024 10:39:03 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37602)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1tAsyr-0006Lt-F6
 for 66912 <at> debbugs.gnu.org; Tue, 12 Nov 2024 10:39:02 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 214C944475D;
 Tue, 12 Nov 2024 10:38:50 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1731425928;
 bh=49B++KYDKW/xb41cKHHRBgUdjFWrK2oWW6rRGTS3izU=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=MzBi6lkurnt3+6rzb/yfLU2sxB/p0OtddMYqsB6wfpn4xSQu9tyayVqnsWsL3oTwO
 +/QVOmUcfxihFo6Z86p2cWFSOEQsxPs4yKcynQioMjzHGH12JmeMSOXxnyejysqOXi
 M85O+EiaCD1hCYyPoiD3WyAn6aTrs3QN2KnmsybegvGKewIRqEObNgd12QdfWhCoKd
 USJk16pwhpannBE7oynLnBvgmv0UJ4Kw+bsfFyTtssi8xu6MSviv/m5wkUUhAIf1Gn
 eU/XCsBcL/hC6wLWQ3Ehxl3AnBAZLRDF5bBbbHrzzzO/xGQZFQgtHcoyCRdnW4pX8/
 jGrcTqJej7wwA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9976A444757;
 Tue, 12 Nov 2024 10:38:48 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6BA4912062E;
 Tue, 12 Nov 2024 10:38:48 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZzNsBGpp-AZLSQaU@HIDDEN> (Alan Mackenzie's message of
 "Tue, 12 Nov 2024 14:53:56 +0000")
Message-ID: <jwvfrnwtrf9.fsf-monnier+emacs@HIDDEN>
References: <Zyz1xWXcfEghUWOa@HIDDEN>
 <jwvzfm926lx.fsf-monnier+emacs@HIDDEN>
 <Zy5uMii0Fw-sz_MW@HIDDEN>
 <jwvr07lo4y3.fsf-monnier+emacs@HIDDEN>
 <Zy9XB1TaxjBSQ1im@HIDDEN>
 <jwv8qtsz7wc.fsf-monnier+emacs@HIDDEN>
 <ZzCNn0nMmXuBqgpA@HIDDEN>
 <jwv7c9bxd41.fsf-monnier+emacs@HIDDEN>
 <ZzDx4wbwZwwtH3Ew@HIDDEN>
 <jwv8qtqwzcn.fsf-monnier+emacs@HIDDEN>
 <ZzNsBGpp-AZLSQaU@HIDDEN>
Date: Tue, 12 Nov 2024 10:38:47 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.039 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> OK, so you were using "the point in the chain where we catch the
> error", which is of no interest to the user, as a proxy for how and
> where an error message gets displayed.

I conflate the two, yes.

> I thought we were agreed that the "A =3D> B =3D> compile =3D> C =3D> D" w=
as
> vanishingly rare and probably doesn't occur at all in the Emacs sources.

I like to think of such corner cases because it gives me more clarity
about the general case.  If I focus only on the scenario at hand it's
all too easy to design something that doesn't work well in the
general case.

> In that case, why are you giving it priority over the other concerns
> (such as consistency of messages displayed to the user) that I have
> raised?

Because I don't see the benefit of using "consistent" messages when
the circumstances are very different.

> Would you please clarify whether you are opposed to outputting the
> information (about the stack of files being loaded) in the debugger
> case, or are merely indifferent about it.

I'm indifferent about it.
But I do care about the debugger showing me the error *object* rather
than merely the error *message*.

> It is true that Emacs error messages are typically poor in the extreme,
> in that they fail to identify the pertinent command, buffer, hook, or
> variable.  I have been trying to improve this for several years, with
> mixed success.  The thing about loading is that it is frequently
> recursive, typically by the function `require'.  Being told which file
> the failing Lisp came from is as good as saying which buffer, and likely
> better in batch mode.

That's why I'm thinking of generalizing the `load-in-progress-at-error`
into a `dynamic-context-at-error` where we could stash arbitrarily more
information.  Ideally, error objects would come with a full backtrace,
from which we could extract the stack of pending loads, the name of the
current command, or process filter, or hooks, ...
[ In SML/NJ, exception objects keep a reference to the "stack" for that
  purpose, but of course, that's easy for them because they heap
  allocate their "stack", so it's a simple matter of keeping
  a reference, whereas we'd have to copy our "stack", which could
  slow down `signal` significantly.  ]

>> > I think it would be consistent to display "While loading..." the same
>> > in both cases.
>
>> To be honest, I don't see much value in displaying "while loading" in
>> the echo area in general.
>
> To be frank, displaying nothing but
>
>     Wrong type argument: integer-or-marker-p, nil
>
> to the user is insulting.

Agreed.  At the same time, it corresponds to Python dumping a backtrace
onto the unsuspecting user, or C crashing down with a core dump, so
I think we're in good company.

IOW when the end user sees such an error message, it means we have a bug
in the ELisp code somewhere.  The bug is either in that we should not
trigger this error, or that we should catch it and turn it into an error
that's meaningful in the context of the command where it's executed.

Note that in presence of such a bug, adding "while loading A" won't
really help.
The only two behaviors that would help would be either to drop
into the debugger (so as to help diagnose/find/fix the bug), or to emit
a message explaining to the user that they found a bug (and maybe try
and help them submit a bug report).

Dropping into the debugger is what we get with `debug-on-error`, but
I don't think we can enable it by default, because it's a bit too
delicate to use for some users.  Maybe we should improve that.

> Informing the user which file the error occurred in, though far from
> ideal, is significantly better than not doing so.

IME, the above kind of error usually happens outside of loading files,
so bug#66912 will almost never make a difference for that kind of error.

>> I'm not opposed to it, but the only case where I know it could be
>> helpful is during compilation (which I'm mostly interested to see it
>> in the compilation buffer).
> In this case, the error message is indeed displayed in *Compile-Log*.

=F0=9F=99=82


        Stefan

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.