GNU logs - #74294, boring messages

Message sent to monnier@HIDDEN, bug-gnu-emacs@HIDDEN:

Subject: bug#74294: Master: debug-on-error is ineffective whilst requiring a file from the byte compiler.
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: monnier@HIDDEN, bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 10 Nov 2024 13:06:02 +0000
Resent-Message-ID: <handler.74294.B.17312439503157 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 74294 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier@HIDDEN>
Date: Sun, 10 Nov 2024 13:05:36 +0000
Message-ID: <ZzCvoEewfYAUy73l@HIDDEN>
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,
 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
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: -2.4 (--)

Hello, Emacs.

In master (any recent version):

Create the following files:

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

2: ~/test-byte-compile-errors-2.el:
#########################################################################
;; -*- lexical-binding:t -*-
(car 'baz)

(provide 'test-byte-compile-errors-2)
#########################################################################

(Note the erroneous (car 'baz) in this file.)

(i) emacs -Q
(ii) M-: (setq debug-on-error t) RET
(iii) M-x byte-compile-file RET ~/test-byte-compile-errors.el RET

(iv) The error message:

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

is displayed.  The debugger is not run.  This is surely a bug.

(Note also, the file name displayed is not that where the error is: See
bug#66912.)

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

Diagnosis
---------

In the function bytecomp--displaying-warnings (bytecomp.el), a blocking
condition-case is set up, except when byte-compile-debug is non-nil.
This prevents the debugger running.  The problem is, the effect of this
condition-case prevails even outside the byte compiler whilst loading a
file with `require'.

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

Proposed Resolution
-------------------

Set up one or more handler-binds around the parts of Fload that evaluate
the contents of the file being loaded.  In the event of an error, the
handler-bind handler would trigger, test debug-on-error, and if it's set
appropriately, call the debugger, then quit.  Otherwise, the handler
would return, and the error handling would eventually reach the
condition-case set up by bytecomp--displaying-warnings.

-- 
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#74294: Acknowledgement (Master: debug-on-error is ineffective
 whilst requiring a file from the byte compiler.)
Message-ID: <handler.74294.B.17312439503157.ack <at> debbugs.gnu.org>
References: <ZzCvoEewfYAUy73l@HIDDEN>
X-Gnu-PR-Message: ack 74294
X-Gnu-PR-Package: emacs
Reply-To: 74294 <at> debbugs.gnu.org
Date: Sun, 10 Nov 2024 13:06: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.

As you requested using X-Debbugs-CC, your message was also forwarded to
  Stefan Monnier <monnier@HIDDEN>
(after having been given a bug report number, if it did not have one).

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 74294 <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
74294: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D74294
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#74294: Master: debug-on-error is ineffective whilst requiring a file from the byte compiler.
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 17:32:01 +0000
Resent-Message-ID: <handler.74294.B74294.173125991817001 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Alan Mackenzie <acm@HIDDEN>
Cc: 74294 <at> debbugs.gnu.org
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <ZzCvoEewfYAUy73l@HIDDEN> (Alan Mackenzie's message of
 "Sun, 10 Nov 2024 13:05:36 +0000")
Message-ID: <jwvpln3vwa5.fsf-monnier+emacs@HIDDEN>
References: <ZzCvoEewfYAUy73l@HIDDEN>
Date: Sun, 10 Nov 2024 12:31:46 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Create the following files:
>
> 1: ~/test-byte-compile-errors.el:
> #########################################################################
> ;; -*- lexical-binding:t -*-
> (require 'test-byte-compile-errors-2 "~/test-byte-compile-errors-2")
> #########################################################################
>
> 2: ~/test-byte-compile-errors-2.el:
> #########################################################################
> ;; -*- lexical-binding:t -*-
> (car 'baz)
>
> (provide 'test-byte-compile-errors-2)
> #########################################################################
>
> (Note the erroneous (car 'baz) in this file.)
>
> (i) emacs -Q
> (ii) M-: (setq debug-on-error t) RET
> (iii) M-x byte-compile-file RET ~/test-byte-compile-errors.el RET
>
> (iv) The error message:
>
>     test-byte-compile-errors.el:2:11: Error: Wrong type argument: listp, baz
>
> is displayed.  The debugger is not run.  This is surely a bug.
>
> (Note also, the file name displayed is not that where the error is: See
> bug#66912.)
>
> #########################################################################
>
> Diagnosis
> ---------
>
> In the function bytecomp--displaying-warnings (bytecomp.el), a blocking
> condition-case is set up, except when byte-compile-debug is non-nil.
> This prevents the debugger running.  The problem is, the effect of this
> condition-case prevails even outside the byte compiler whilst loading a
> file with `require'.

Hmm... whether it's "outside the byte compiler" or not is debatable.
[ FWIW, I've been annoyed by the behavior as well, but just decided to set
  `byte-compile-debug` to t in my init file, and life is bliss since then.  ]

> Set up one or more handler-binds around the parts of Fload that evaluate
> the contents of the file being loaded.  In the event of an error, the
> handler-bind handler would trigger, test debug-on-error, and if it's set
> appropriately, call the debugger, then quit.  Otherwise, the handler
> would return, and the error handling would eventually reach the
> condition-case set up by bytecomp--displaying-warnings.

Is the problem specific to `load`, really?
What about errors within `eval-when-compile` or during the expansion of
one of the macros?

Also, do you really want to bring up the debugger in cases like

    (eval-when-compile
      (condition-case nil
          (require ...)
        (error ...)))

which I've seen used in a few packages out there?

        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#74294: Master: debug-on-error is ineffective whilst requiring a file from the byte compiler.
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 18:39:01 +0000
Resent-Message-ID: <handler.74294.B74294.173126391828422 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Cc: acm@HIDDEN, 74294 <at> debbugs.gnu.org
Date: Sun, 10 Nov 2024 18:38:26 +0000
Message-ID: <ZzD9ogVKW9E4ilKY@HIDDEN>
References: <ZzCvoEewfYAUy73l@HIDDEN>
 <jwvpln3vwa5.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvpln3vwa5.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 Sun, Nov 10, 2024 at 12:31:46 -0500, Stefan Monnier wrote:
> > Create the following files:

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

> > 2: ~/test-byte-compile-errors-2.el:
> > #########################################################################
> > ;; -*- lexical-binding:t -*-
> > (car 'baz)

> > (provide 'test-byte-compile-errors-2)
> > #########################################################################

> > (Note the erroneous (car 'baz) in this file.)

> > (i) emacs -Q
> > (ii) M-: (setq debug-on-error t) RET
> > (iii) M-x byte-compile-file RET ~/test-byte-compile-errors.el RET

> > (iv) The error message:

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

> > is displayed.  The debugger is not run.  This is surely a bug.

> > (Note also, the file name displayed is not that where the error is: See
> > bug#66912.)

> > #########################################################################

> > Diagnosis
> > ---------

> > In the function bytecomp--displaying-warnings (bytecomp.el), a blocking
> > condition-case is set up, except when byte-compile-debug is non-nil.
> > This prevents the debugger running.  The problem is, the effect of this
> > condition-case prevails even outside the byte compiler whilst loading a
> > file with `require'.

> Hmm... whether it's "outside the byte compiler" or not is debatable.

Well for sure, we're not processing functions beginning "byte-compile-"
at the time.  And perhaps most pertinently, an error in Fload doesn't
(?can't be made to) invoke the byte compiler's error mechanism
satisfactorally.

> [ FWIW, I've been annoyed by the behavior as well, but just decided to set
>   `byte-compile-debug` to t in my init file, and life is bliss since then.  ]

That's fine for those who know about byte-compile-debug.  I suspect the
vast majority of users don't.  And it's a hassle to have to run something
THREE times to get a backtrace:  The first time the error happens, the
second time the user sets debug-on-error, then after considerable
frustration and looking up of the elisp manual, the third time with
byte-compile-debug set too.

There might be an argument here for removing byte-compile-debug and that
condition-case altogether, but that's not what I'm arguing at the moment.

> > Set up one or more handler-binds around the parts of Fload that evaluate
> > the contents of the file being loaded.  In the event of an error, the
> > handler-bind handler would trigger, test debug-on-error, and if it's set
> > appropriately, call the debugger, then quit.  Otherwise, the handler
> > would return, and the error handling would eventually reach the
> > condition-case set up by bytecomp--displaying-warnings.

> Is the problem specific to `load`, really?

Yes, I think it is.  Because it is precisely during Fload called from the
byte compiler when a signalled error gives no clue as to the source of
that error.

> What about errors within `eval-when-compile` or during the expansion of
> one of the macros?

Errors there will say where they have happened, more or less.

> Also, do you really want to bring up the debugger in cases like

>     (eval-when-compile
>       (condition-case nil
>           (require ...)
>         (error ...)))

> which I've seen used in a few packages out there?

When debug-on-error is enabled, yes.  To do everything the way we'd like,
we don't have enough control levers.  It is probably better to enter the
debugger in the above case (the user did set debug-on-error after all)
than not enter it when an error happens in a deep stack of `require's.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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.