From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 16 19:37:44 2023 Received: (at submit) by debbugs.gnu.org; 17 Dec 2023 00:37:44 +0000 Received: from localhost ([127.0.0.1]:56373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEfA6-0006Gt-UT for submit@debbugs.gnu.org; Sat, 16 Dec 2023 19:37:43 -0500 Received: from lists.gnu.org ([2001:470:142::17]:39094) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEfA3-0006Gd-HF for submit@debbugs.gnu.org; Sat, 16 Dec 2023 19:37:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rEf9x-0001uW-2z for bug-gnu-emacs@gnu.org; Sat, 16 Dec 2023 19:37:33 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rEf9u-000894-0q for bug-gnu-emacs@gnu.org; Sat, 16 Dec 2023 19:37:32 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1FD0B100068 for ; Sat, 16 Dec 2023 19:37:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1702773446; bh=84xp+Poqlv2M9jBBMJU0nzFHUYjv2/cDJMVuIFZYBa8=; h=From:To:Subject:Date:From; b=Iu80kXHPMx0Ahw1UT4UHPzCjSdTjbz5cXGljQycrUSLEbvE5flCHxbwIiJIYT6XFV peL4Po9jqz1ybMP4nqV1a2UK1nfaC+rHG6qmirBJzs2Z+dKypHmJNUrZDS/czQgDk/ VRrULRGaMaSjdQ1B8KjV/SC0Q3XxMO63TbOjcH4u9UI6NYZCkU9gC6K71f8AwjXIGh zZMco4IlUCUYseiMrDkYIHzAepWcyd/NdUXwq40hMUyzlj8wEfxGw0eKjs+1VibfEo ao9ZqbAzpOh5D6RJMRXWVBR62qwAIlQFK7aFOioT7+DVuqazImw2jnVfJIjDVseq+p UwNR3CfzXLUYQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0C66C100033 for ; Sat, 16 Dec 2023 19:37:26 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DA0511211D3 for ; Sat, 16 Dec 2023 19:37:25 -0500 (EST) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: 30.0.50; Handler-bind and ert-test-error-debug X-Debbugs-Cc: Christian Ohler Date: Sat, 16 Dec 2023 19:37:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.031 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: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; 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-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Package: Emacs Version: 30.0.50 `condition-case` has served us well for the usual error handling needs of common code, but it does not let us capture information about the dynamic context where the error takes place, such as capturing the value of dynamically scoped vars or the backtrace. For that reason, `signal_or_quit` has slowly grown as new needs have come up to run various kinds of debugger-like operations in special cases. The attached patch adds the new special form `handler-bind` which provides a functionality similar to `condition-case` except that the handler is run *before* unwinding the stack. The patch includes a change to `ert.el` to make use of it to capture the backtrace of errors instead of messing with `debugger` and `debug-on-error`, which is fiddly and comes with various problems (such as the fact that it impacts `condition-case-unless-debug`). It's not completely finished but I'm bumping into a question. `ert-tests.el` includes the following test: (ert-deftest ert-test-error-debug () (let ((test (make-ert-test :body (lambda () (error "Error message"))))) (condition-case condition (progn (let ((ert-debug-on-error t)) (ert-run-test test)) (cl-assert nil)) ((error) (cl-assert (equal condition '(error "Error message")) t))))) Until now, this test passes just like that, i.e. without entering the debugger. With the new code, this test does enter the debugger. Can anyone give me a hand figuring out why/how the debugger is not entered with the current code? AFAICT when running the inner `ert-run-test`, we get to `ert--run-test-internal` which sets `debugger` to a function that calls `ert--run-test-debugger` and `debug-on-error` to t, yet when it calls `(error "Error message")` this debugger-function is not called (or at least `ert--run-test-debugger` is not called), which I can't explain. Stefan --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=handler-bind.patch diff --git a/lisp/emacs-lisp/ert.el b/lisp/emacs-lisp/ert.el index 84b50777684..f73abee1587 100644 --- a/lisp/emacs-lisp/ert.el +++ b/lisp/emacs-lisp/ert.el @@ -278,13 +278,12 @@ ert--signal-should-execution (when ert--should-execution-observer (funcall ert--should-execution-observer form-description))) -;; See Bug#24402 for why this exists +;; See Bug#24402 for why this existed. Now we keep it simply +;; for the sake of old `.elc' files compiled with an old `ert.el'. (defun ert--should-signal-hook (error-symbol data) - "Stupid hack to stop `condition-case' from catching ert signals. -It should only be stopped when ran from inside `ert--run-test-internal'." - (when (and (not (symbolp debugger)) ; only run on anonymous debugger - (memq error-symbol '(ert-test-failed ert-test-skipped))) - (funcall debugger 'error (cons error-symbol data)))) + (declare (obsolete nil "30.1")) + (let ((signal-hook-function nil)) + (signal error-symbol data))) (defun ert--special-operator-p (thing) "Return non-nil if THING is a symbol naming a special operator." @@ -324,8 +323,7 @@ ert--expand-should-1 (default-value (gensym "ert-form-evaluation-aborted-"))) `(let* ((,fn (function ,fn-name)) (,args (condition-case err - (let ((signal-hook-function #'ert--should-signal-hook)) - (list ,@arg-forms)) + (list ,@arg-forms) (error (progn (setq ,fn #'signal) (list (car err) (cdr err))))))) @@ -728,78 +726,65 @@ ert--test-execution-info ;; value and test execution should be terminated. Should not ;; return. (exit-continuation (cl-assert nil)) - ;; The binding of `debugger' outside of the execution of the test. - next-debugger ;; The binding of `ert-debug-on-error' that is in effect for the ;; execution of the current test. We store it to avoid being ;; affected by any new bindings the test itself may establish. (I ;; don't remember whether this feature is important.) ert-debug-on-error) -(defun ert--run-test-debugger (info args) - "During a test run, `debugger' is bound to a closure that calls this function. +(defun ert--run-test-debugger (info condition) + "Error handler used during the test run. This function records failures and errors and either terminates the test silently or calls the interactive debugger, as appropriate. -INFO is the ert--test-execution-info corresponding to this test -run. ARGS are the arguments to `debugger'." - (cl-destructuring-bind (first-debugger-arg &rest more-debugger-args) - args - (cl-ecase first-debugger-arg - ((lambda debug t exit nil) - (apply (ert--test-execution-info-next-debugger info) args)) - (error - (let* ((condition (car more-debugger-args)) - (type (cl-case (car condition) - ((quit) 'quit) - ((ert-test-skipped) 'skipped) - (otherwise 'failed))) - ;; We store the backtrace in the result object for - ;; `ert-results-pop-to-backtrace-for-test-at-point'. - ;; This means we have to limit `print-level' and - ;; `print-length' when printing result objects. That - ;; might not be worth while when we can also use - ;; `ert-results-rerun-test-at-point-debugging-errors', - ;; (i.e., when running interactively) but having the - ;; backtrace ready for printing is important for batch - ;; use. - ;; - ;; Grab the frames above the debugger. - (backtrace (cdr (backtrace-get-frames debugger))) - (infos (reverse ert--infos))) - (setf (ert--test-execution-info-result info) - (cl-ecase type - (quit - (make-ert-test-quit :condition condition - :backtrace backtrace - :infos infos)) - (skipped - (make-ert-test-skipped :condition condition - :backtrace backtrace - :infos infos)) - (failed - (make-ert-test-failed :condition condition - :backtrace backtrace - :infos infos)))) - ;; Work around Emacs's heuristic (in eval.c) for detecting - ;; errors in the debugger. - (cl-incf num-nonmacro-input-events) - ;; FIXME: We should probably implement more fine-grained - ;; control a la non-t `debug-on-error' here. - (cond - ((ert--test-execution-info-ert-debug-on-error info) - (apply (ert--test-execution-info-next-debugger info) args)) - (t)) - (funcall (ert--test-execution-info-exit-continuation info))))))) +INFO is the `ert--test-execution-info' corresponding to this test run. +ERR is the error object." + (let* ((type (cl-case (car condition) + ((quit) 'quit) + ((ert-test-skipped) 'skipped) + (otherwise 'failed))) + ;; We store the backtrace in the result object for + ;; `ert-results-pop-to-backtrace-for-test-at-point'. + ;; This means we have to limit `print-level' and + ;; `print-length' when printing result objects. That + ;; might not be worth while when we can also use + ;; `ert-results-rerun-test-at-point-debugging-errors', + ;; (i.e., when running interactively) but having the + ;; backtrace ready for printing is important for batch + ;; use. + ;; + ;; Grab the frames above ourselves. + (backtrace (cdr (backtrace-get-frames 'ert--run-test-debugger))) + (infos (reverse ert--infos))) + (setf (ert--test-execution-info-result info) + (cl-ecase type + (quit + (make-ert-test-quit :condition condition + :backtrace backtrace + :infos infos)) + (skipped + (make-ert-test-skipped :condition condition + :backtrace backtrace + :infos infos)) + (failed + (make-ert-test-failed :condition condition + :backtrace backtrace + :infos infos)))) + ;; FIXME: We should probably implement more fine-grained + ;; control a la non-t `debug-on-error' here. + (cond + ((ert--test-execution-info-ert-debug-on-error info) + (apply debugger 'error condition)) + (t)) + (funcall (ert--test-execution-info-exit-continuation info)))) (defun ert--run-test-internal (test-execution-info) "Low-level function to run a test according to TEST-EXECUTION-INFO. This mainly sets up debugger-related bindings." - (setf (ert--test-execution-info-next-debugger test-execution-info) debugger - (ert--test-execution-info-ert-debug-on-error test-execution-info) + (setf (ert--test-execution-info-ert-debug-on-error test-execution-info) ert-debug-on-error) (catch 'ert--pass ;; For now, each test gets its own temp buffer and its own @@ -807,26 +792,14 @@ ert--run-test-internal ;; too expensive, we can remove it. (with-temp-buffer (save-window-excursion - ;; FIXME: Use `signal-hook-function' instead of `debugger' to - ;; handle ert errors. Once that's done, remove - ;; `ert--should-signal-hook'. See Bug#24402 and Bug#11218 for - ;; details. - (let ((lexical-binding t) - (debugger (lambda (&rest args) - (ert--run-test-debugger test-execution-info - args))) - (debug-on-error t) - ;; Don't infloop if the error being called is erroring - ;; out, and we have `debug-on-error' bound to nil inside - ;; the test. - (backtrace-on-error-noninteractive nil) - (debug-on-quit t) - ;; FIXME: Do we need to store the old binding of this - ;; and consider it in `ert--run-test-debugger'? - (debug-ignored-errors nil) + (let ((lexical-binding t) ;;FIXME: Why? (ert--infos '())) - (funcall (ert-test-body (ert--test-execution-info-test - test-execution-info)))))) + (handler-bind (((error quit) + (lambda (err) + (ert--run-test-debugger test-execution-info + err)))) + (funcall (ert-test-body (ert--test-execution-info-test + test-execution-info))))))) (ert-pass)) (setf (ert--test-execution-info-result test-execution-info) (make-ert-test-passed)) @@ -1553,7 +1526,9 @@ ert-run-tests-batch-and-exit (or noninteractive (user-error "This function is only for use in batch mode")) (let ((eln-dir (and (featurep 'native-compile) - (make-temp-file "test-nativecomp-cache-" t)))) + (make-temp-file "test-nativecomp-cache-" t))) + ;; Don't ever wait for user input. + (inhibit-interaction t)) (when eln-dir (startup-redirect-eln-cache eln-dir)) ;; Better crash loudly than attempting to recover from undefined diff --git a/lisp/subr.el b/lisp/subr.el index 7b52f4f68f9..7cc5d9ac79b 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -7496,6 +7496,36 @@ match-buffers (push buf bufs))) bufs)) +(defmacro handler-bind (handlers &rest body) + "Setup error HANDLERS around execution of BODY. +HANDLERS is a list of (CONDITIONS HANDLER) where +CONDITIONS should be a list of condition names (symbols) or +a single condition name and HANDLER is a form whose evaluation +returns a function. +When an error is signaled during execution of BODY, if that +error matches CONDITIONS, then the associated HANDLER +function is called with the error as argument. +HANDLERs can either transfer the control via a non-local exit, +or return normally. If they return normally the search for an +error handler continues from where it left off." + ;; FIXME: Completion support as in `condition-case'? + (declare (indent 1) (debug ((&rest (sexp form)) body))) + (let ((args '()) + (bindings '())) + (dolist (cond+handler (reverse handlers)) + (let ((handler (car (cdr cond+handler))) + (conds (car cond+handler)) + (handlersym (gensym "handler"))) + (push (list handlersym handler) bindings) + (if (not (listp conds)) + (progn + (push handlersym args) + (push `',conds args)) + (dolist (cond conds) + (push handlersym args) + (push `',cond args))))) + `(let ,bindings (handler-bind-1 (lambda () ,@body) ,@args)))) + (defmacro with-memoization (place &rest code) "Return the value of CODE and stash it in PLACE. If PLACE's value is non-nil, then don't bother evaluating CODE diff --git a/src/eval.c b/src/eval.c index 12e811ce264..075fbf01238 100644 --- a/src/eval.c +++ b/src/eval.c @@ -1355,6 +1355,42 @@ or (:success BODY...), where the BODY is made of Lisp expressions. return internal_lisp_condition_case (var, bodyform, handlers); } +DEFUN ("handler-bind-1", Fhandler_bind_1, Shandler_bind_1, 1, MANY, 0, + doc: /* Setup error handlers around execution of BODYFUN. +BODYFUN be a function and it is called with no arguments. +CONDITION should be a condition name (symbol). +When an error is signaled during executon of BODYFUN, if that +error matches CONDITION, 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, it should return a new +error object or nil, and the search for an error handler continues +from where it left off, using the new error object returned by +HANDLER (or the old error object if it returned nil). + +(fn BODYFUN [CONDITION HANDLER]...) */) + (ptrdiff_t nargs, Lisp_Object *args) +{ + eassert (nargs >= 1); + Lisp_Object bodyfun = args[0]; + Lisp_Object map = Qnil; + ptrdiff_t i = 2; + while (i < nargs) + { + Lisp_Object condition = args[i - 1], handler = args[i]; + map = Fcons (Fcons (condition, handler), map); + i += 2; + } + /* FIXME: Fsignal handles multiple conditions&handlers */ + struct handler *current_handlerlist = handlerlist; + push_handler (Fnreverse (map), HANDLER); + eassert (handlerlist->next == current_handlerlist); + Lisp_Object ret = call0 (bodyfun); + eassert (handlerlist->next == current_handlerlist); + handlerlist = handlerlist->next; + return ret; +} + /* Like Fcondition_case, but the args are separate rather than passed in a list. Used by Fbyte_code. */ @@ -1731,6 +1767,7 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit) = (NILP (error_symbol) ? Fcar (data) : error_symbol); Lisp_Object clause = Qnil; struct handler *h; + int skip; if (gc_in_progress || waiting_for_input) emacs_abort (); @@ -1772,16 +1809,60 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit) Vsignaling_function = backtrace_function (pdl); } - for (h = handlerlist; h; h = h->next) + for (skip = 0, h = handlerlist; h; skip++, h = h->next) { - if (h->type == CATCHER_ALL) + switch (h->type) { + case CATCHER_ALL: clause = Qt; break; - } - if (h->type != CONDITION_CASE) - continue; - clause = find_handler_clause (h->tag_or_ch, conditions); + case CATCHER: + continue; + case CONDITION_CASE: + clause = find_handler_clause (h->tag_or_ch, conditions); + break; + case HANDLER: + { + Lisp_Object handlers = h->tag_or_ch; + for (; CONSP (handlers); handlers = XCDR (handlers)) + { + Lisp_Object handler = XCAR (handlers); + if (CONSP (handler) + && !NILP (Fmemq (XCAR (handler), conditions))) + { + struct handler *current_handlerlist = handlerlist; + Lisp_Object error_data + = (NILP (error_symbol) + ? data : Fcons (error_symbol, data)); + /* FIXME: This inhibits deeper catchers, + which isn't right! */ + push_handler (make_fixnum (skip), SKIP_CONDITIONS); + eassert (handlerlist->next == current_handlerlist); + Lisp_Object retval = call1 (XCDR (handler), error_data); + /* Pop the SKIP_CONDITIONS. No need to use unwind_protect + since any non-local exit will set 'handlerlist'. */ + eassert (handlerlist->next == current_handlerlist); + handlerlist = current_handlerlist; + if (CONSP (retval)) + { + error_symbol = XCAR (retval); + data = XCDR (retval); + conditions = Fget (error_symbol, Qerror_conditions); + } + } + } + continue; + } + case SKIP_CONDITIONS: + { + int toskip = XFIXNUM (h->tag_or_ch); + while (toskip-- >= 0) + h = h->next; + continue; + } + default: + abort (); + } if (!NILP (clause)) break; } @@ -1798,7 +1879,7 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit) || (CONSP (clause) && !NILP (Fmemq (Qdebug, clause))) /* Special handler that means "print a message and run debugger if requested". */ - || EQ (h->tag_or_ch, Qerror))) + || EQ (clause, Qerror))) { debugger_called = maybe_call_debugger (conditions, error_symbol, data); @@ -1813,7 +1894,7 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit) to not interfere with ERT or other packages that install custom debuggers. */ if (!debugger_called && !NILP (error_symbol) - && (NILP (clause) || EQ (h->tag_or_ch, Qerror)) + && (NILP (clause) || EQ (clause, Qerror)) && noninteractive && backtrace_on_error_noninteractive && NILP (Vinhibit_debugger) && !NILP (Ffboundp (Qdebug_early))) @@ -2052,13 +2133,10 @@ find_handler_clause (Lisp_Object handlers, Lisp_Object conditions) register Lisp_Object h; /* t is used by handlers for all conditions, set up by C code. */ - if (EQ (handlers, Qt)) - return Qt; - /* error is used similarly, but means print an error message and run the debugger if that is enabled. */ - if (EQ (handlers, Qerror)) - return Qt; + if (!CONSP (handlers)) + return handlers; for (h = handlers; CONSP (h); h = XCDR (h)) { @@ -4449,6 +4527,7 @@ syms_of_eval (void) defsubr (&Sthrow); defsubr (&Sunwind_protect); defsubr (&Scondition_case); + defsubr (&Shandler_bind_1); DEFSYM (QCsuccess, ":success"); defsubr (&Ssignal); defsubr (&Scommandp); diff --git a/src/lisp.h b/src/lisp.h index df6cf1df544..33892eb4a68 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3618,7 +3618,8 @@ record_in_backtrace (Lisp_Object function, Lisp_Object *args, ptrdiff_t nargs) Members are volatile if their values need to survive _longjmp when a 'struct handler' is a local variable. */ -enum handlertype { CATCHER, CONDITION_CASE, CATCHER_ALL }; +enum handlertype { CATCHER, CONDITION_CASE, CATCHER_ALL, + HANDLER, SKIP_CONDITIONS }; enum nonlocal_exit { --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 17 01:53:57 2023 Received: (at 67862) by debbugs.gnu.org; 17 Dec 2023 06:53:57 +0000 Received: from localhost ([127.0.0.1]:56531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEl2D-0006Lg-G0 for submit@debbugs.gnu.org; Sun, 17 Dec 2023 01:53:57 -0500 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:58643) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEl2A-0006LN-9i for 67862@debbugs.gnu.org; Sun, 17 Dec 2023 01:53:56 -0500 Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-33666255281so81484f8f.1 for <67862@debbugs.gnu.org>; Sat, 16 Dec 2023 22:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702796027; x=1703400827; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=vBTAaoU8rok6rgwVUo3nB/OqZ4LrByi9UUZHdhcT2I4=; b=OBbZ/ffHs+IoUgTuzPPT2zW9gq0aC8WdDtNi8gh3iUKVv8RhaX0uaJU7TzWv8GHQkN ogrq7RUhwdOTVGRykhbOmh0ebaRaHTdf6XSE17S10cPV5mw7oL+PUEt0cZLzWtDFaoaq lcLRdIi6ls+UZYZG/SVDTgWur3Y8+XGPNGPI68wa0YibtTvFJXEmhjcjNwsqaakfUteC lRSx1znCjdNQI8RJP094Ag8yAC0jo50jmBy0WoxSEoRHR/4joYM+yrghROWyMIZ13FHE zp9wLTarXJgScTeNs4Acf+23Utc+QVM9z3aDPci6WRUQZDv+jd1wbye4+EJumypLWfZu rb9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702796027; x=1703400827; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vBTAaoU8rok6rgwVUo3nB/OqZ4LrByi9UUZHdhcT2I4=; b=RpCZnUb1uQwyZvP39tN1YAxJReOsvRL3V9GzuBTZOF6m1BFcmWqoNVz0d0nZyU8yxR PLT5ss9MafVSVCKMjDlm7zY6BB4hXVPDTzb+M8Zi94jYmHAvihpffsfGuEz1CusU+fv7 2p/vqfaDdJJjqrxvmUoFBGh7xQNfwlcwYOFKONQYtleumEk4kAlA21g/aSA37ZrvekTe Z+H1Z8E3zGIsDeevTFVOxtFJO+bZ1nxEJLy5LJ0E2zhalNyRSrjiQeB0eKefJPIFzKgG qDG0h/6SRRTosGDRImxL+meoWXi9+w3tMFqXQkxuLyafF2F4DOGRBmO/G9kAzJl5dhEK AMgg== X-Gm-Message-State: AOJu0Yx16LKrs0OTdjC6gTDBrzz3sDM3KVYA7vFaIiCxIaAUF4RMw4sr NipS5v4e9aux5s0pBQHGDAk= X-Google-Smtp-Source: AGHT+IF1/UulACBEwsMxWDs32GNIRSlrtP6rxidp1iWSIQQPzFTJpaTxVwr+43Y1a9TeI4CFPPXFjg== X-Received: by 2002:a5d:53c7:0:b0:333:2de8:a056 with SMTP id a7-20020a5d53c7000000b003332de8a056mr3939755wrw.8.1702796026823; Sat, 16 Dec 2023 22:53:46 -0800 (PST) Received: from Pro.fritz.box (p4fe3a6db.dip0.t-ipconnect.de. [79.227.166.219]) by smtp.gmail.com with ESMTPSA id r10-20020a508d8a000000b0054cb88a353dsm9131952edh.14.2023.12.16.22.53.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Dec 2023 22:53:46 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug In-Reply-To: (Stefan Monnier's message of "Sat, 16 Dec 2023 19:37:14 -0500") References: Date: Sun, 17 Dec 2023 07:53:44 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67862 Cc: 67862@debbugs.gnu.org, Christian Ohler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > (ert-deftest ert-test-error-debug () > (let ((test (make-ert-test :body (lambda () (error "Error message"))))) > (condition-case condition > (progn > (let ((ert-debug-on-error t)) > (ert-run-test test)) > (cl-assert nil)) > ((error) > (cl-assert (equal condition '(error "Error message")) t))))) > > Until now, this test passes just like that, i.e. without entering > the debugger. With the new code, this test does enter the debugger. > > Can anyone give me a hand figuring out why/how the debugger is not entered > with the current code? Could that be from the condition-case that the test puts around the ert-run-test? Like in (condition-case var (let ((debug-on-error t)) (error "error")) (error "no debugger")) From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 17 10:08:54 2023 Received: (at 67862) by debbugs.gnu.org; 17 Dec 2023 15:08:54 +0000 Received: from localhost ([127.0.0.1]:58872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEslC-0005Hg-H3 for submit@debbugs.gnu.org; Sun, 17 Dec 2023 10:08:54 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:59233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEsl9-0005HQ-VP for 67862@debbugs.gnu.org; Sun, 17 Dec 2023 10:08:52 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DBA8C4422C4; Sun, 17 Dec 2023 10:08:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1702825723; bh=LiV3AMFgS05ALMykBzVhLWTcOEnZjLJme0EIV1PlroU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RyZ83s9XJJYAcIGcf3GKVVvQ4yeaXUDBxNG07hCvZZYgkJHRDFrgq4xNnuWvrbxbL r9C710uCxi1u9G0uChYV/u6gOrvmugePoVmDq3VvDzl8XzdFu68+G5Gn3Wz6LkhbBG YnlCx9A5d9S9CLh7DmaDSWzat1oBlFLxerFuCLhRuR/kqzUbmH7ZNXDUliA60BxyHK Pc79Tk/K8ae8kifXpitMS9gFlaKYGqE6SCWE8lhNy9iaecs2sRJGXN8K3tHqDMjv30 QUaUSDw6m6L9Tj8OZ/VMoVq2YxiHx8LZQt0cNRL0CmBsUi3Cy7DMrqQdZsYebYYSjJ sEGnfh8D04KGQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 80CF4441E34; Sun, 17 Dec 2023 10:08:43 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 49CEA120107; Sun, 17 Dec 2023 10:08:43 -0500 (EST) From: Stefan Monnier To: Gerd =?windows-1252?Q?M=F6llmann?= Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug In-Reply-To: ("Gerd =?windows-1252?Q?M=F6ll?= =?windows-1252?Q?mann=22's?= message of "Sun, 17 Dec 2023 07:53:44 +0100") Message-ID: References: Date: Sun, 17 Dec 2023 10:08:41 -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.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 T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67862 Cc: 67862@debbugs.gnu.org, Christian Ohler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> (ert-deftest ert-test-error-debug () >> (let ((test (make-ert-test :body (lambda () (error "Error message"))))) >> (condition-case condition >> (progn >> (let ((ert-debug-on-error t)) >> (ert-run-test test)) >> (cl-assert nil)) >> ((error) >> (cl-assert (equal condition '(error "Error message")) t))))) >> >> Until now, this test passes just like that, i.e. without entering >> the debugger. With the new code, this test does enter the debugger. >> >> Can anyone give me a hand figuring out why/how the debugger is not entered >> with the current code? > > Could that be from the condition-case that the test puts around the > ert-run-test? Like in > > (condition-case var > (let ((debug-on-error t)) > (error "error")) > (error "no debugger")) Duh! Thanks Gerd for making me see the obvious. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 26 11:42:22 2023 Received: (at 67862) by debbugs.gnu.org; 26 Dec 2023 16:42:22 +0000 Received: from localhost ([127.0.0.1]:34835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIAVa-0000Pd-3Y for submit@debbugs.gnu.org; Tue, 26 Dec 2023 11:42:22 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63270) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIAVW-0000PM-GF for 67862@debbugs.gnu.org; Tue, 26 Dec 2023 11:42:20 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8B58A442183; Tue, 26 Dec 2023 11:25:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703607925; bh=Yeq37jFF+qnH1KmDRW1PGmNrGiF6b/G7wYMJeEjxZng=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BYSzjROUDaYA5YX/LomSsQW+3lJ7ZoKb3fp4gUurdCkgSd5sChqzvWjr9cvdQlAG6 ZOCijR82zJFlj2XVUYoqH7YkXaGJVT7StvqcgLSSIjc052OsQM+/lTl5lblCEw00o7 NV+OTdVgQC7hApW8djmyuNVMCkxVG0RtabmhjFyvXR4vMTkLlC+Gaeb/4FCH8xKXQk TwQbGiWDaREI7WAn5Tp6zB1l68KsLUdYOQsnxJCOqSaBL68rUOkZ/AZ3AoG14J4TyP 5wNbz//OyS3ctN2FEwAxtZG5xD1S+VKCrbfRxshjBXTpFmv6Qi8dznUxypRUz4u2Eh PojsR7V8KxO0g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0F7F1441AE1; Tue, 26 Dec 2023 11:25:25 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D1A8412110F; Tue, 26 Dec 2023 11:25:24 -0500 (EST) From: Stefan Monnier To: Christian Ohler Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug In-Reply-To: ("Gerd =?windows-1252?Q?M=F6ll?= =?windows-1252?Q?mann=22's?= message of "Sun, 17 Dec 2023 07:53:44 +0100") Message-ID: References: Date: Tue, 26 Dec 2023 11:25:22 -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.072 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-Debbugs-Envelope-To: 67862 Cc: Gerd =?windows-1252?Q?M=F6llmann?= , 67862@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> (ert-deftest ert-test-error-debug () >> (let ((test (make-ert-test :body (lambda () (error "Error message"))))) >> (condition-case condition >> (progn >> (let ((ert-debug-on-error t)) >> (ert-run-test test)) >> (cl-assert nil)) >> ((error) >> (cl-assert (equal condition '(error "Error message")) t))))) >> >> Until now, this test passes just like that, i.e. without entering >> the debugger. With the new code, this test does enter the debugger. >> >> Can anyone give me a hand figuring out why/how the debugger is not entered >> with the current code? > > Could that be from the condition-case that the test puts around the > ert-run-test? Like in > > (condition-case var > (let ((debug-on-error t)) > (error "error")) > (error "no debugger")) > OK, so now I understand how that test succeeds, but instead I don't understand why it is expected to succeed or more specifically what it is intended to test. AFAICT (let ((ert-debug-on-error t)) (ert-run-test test)) is supposed to say "run the test and please pop up a debugger if there's an error". The ERT code even goes to the trouble to store&use the value of `ert-debug-on-error` upon entry to the tests rather the value that happens to be current when the error is signaled. So to me the code looks like it wants to test that `ert-debug-on-error` indeed brings up a debugger, tho none of the surrounding code tries to detect whether the debugger is/was entered, and instead that surrounding code uses `condition-case` which prevents entering the debugger. Is it really the purpose of this test to make sure that "even if we ask for the debugger, `condition-case` prevents the use of a debugger"? Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 26 13:00:43 2023 Received: (at 67862) by debbugs.gnu.org; 26 Dec 2023 18:00:43 +0000 Received: from localhost ([127.0.0.1]:34988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIBjO-0000Rb-RN for submit@debbugs.gnu.org; Tue, 26 Dec 2023 13:00:43 -0500 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:44433) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIBjM-00009L-NT for 67862@debbugs.gnu.org; Tue, 26 Dec 2023 13:00:41 -0500 Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5554f268c6cso24970a12.1 for <67862@debbugs.gnu.org>; Tue, 26 Dec 2023 10:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703613636; x=1704218436; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=vHLmAJmcoIqYo9n61odR1Sv8ALziOWomU4a7ue+KI50=; b=KqedE0HTJmNbQTkf/2RhtSmpZtXyLwf0uWbDm/Cta8Ptv3x/1hsHhw49udKIjnMysR siy4jg1b+kX68J0O9fAdkU+eavoTt96iLMLrhRJCQDwiZNLIj3O+04LxrAKKxuWUO4sZ ZJaGRlc/baic39mIfTOD55JRarASoWw814sfs4kFyaZfEWxl+rQcDAHU9ldmaX0WBZPI PvyAFPt11R48Cg/8iB9e5nyIj8TJjQDQS1lCq3iL6YKDnphaUA43pgdPPh2RWvlmYcrH u9rVOpYluV9vVq/wp34+i14/l6Wefp3Uu24UduRkK5y4ka97HTL2Kdnbaq+CwujA6L9J OPOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703613636; x=1704218436; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vHLmAJmcoIqYo9n61odR1Sv8ALziOWomU4a7ue+KI50=; b=NWVlAA+6MyG2y9bgSGSH9UWbabv/DCzoldd1vblCNveOzAhCUml+ojDtcoqSYkNVcS pcdt2ZlNiLTxtSteaoCdhKMtt3d/x4yL4hAWRhAfSLFRbH2fo4qRZlk0YLN369TXjQtL gwwYz/LPxgTFUZ6tdgLE1XZGQ9V5lK384O0UNxcCEX+X06QIKngtKqcB8NoAsTgrFR5y rpvZRt3Hyr30SBoRHb+XEM5zjjnvWVVNM37TuA/aLQeYllLGXPktNMAia0jTqEoFc/oY SCfxqGiJQ0OmALUTFTo0TZYQKI9lsOQCzpBhf4bairuQRgFXW7dEpPObpjLNrmkforXA TFHw== X-Gm-Message-State: AOJu0YyLTl0x9M6itCLgji5o1OjqbgFboz+3ix5TyNqIh3JX0PoP6bEK BuvIIID8q0jV4Crl25M/XEW0vBMZ/eI= X-Google-Smtp-Source: AGHT+IGesSYuXgKJf40fMGrR+IZfr2H5/5e/+t/qSptOyv6KncO563mjG5zI4AqWWuVEwUdT4M6tcQ== X-Received: by 2002:a50:8adc:0:b0:548:e0d0:de86 with SMTP id k28-20020a508adc000000b00548e0d0de86mr5432003edk.39.1703613635898; Tue, 26 Dec 2023 10:00:35 -0800 (PST) Received: from Pro.fritz.box (pd9e36182.dip0.t-ipconnect.de. [217.227.97.130]) by smtp.gmail.com with ESMTPSA id x7-20020a50ba87000000b005527cfaa2dfsm7821701ede.49.2023.12.26.10.00.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Dec 2023 10:00:35 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug In-Reply-To: (Stefan Monnier's message of "Tue, 26 Dec 2023 11:25:22 -0500") References: Date: Tue, 26 Dec 2023 19:00:34 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67862 Cc: 67862@debbugs.gnu.org, Christian Ohler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > AFAICT > > (let ((ert-debug-on-error t)) > (ert-run-test test)) > > is supposed to say "run the test and please pop up a debugger if there's > an error". The ERT code even goes to the trouble to store&use the value of > `ert-debug-on-error` upon entry to the tests rather the value that > happens to be current when the error is signaled. That's also what I've seen in ert.el, and how I think things are supposed to work. > So to me the code looks like it wants to test that `ert-debug-on-error` > indeed brings up a debugger, tho none of the surrounding code tries to > detect whether the debugger is/was entered, and instead that surrounding > code uses `condition-case` which prevents entering the debugger. > > Is it really the purpose of this test to make sure that "even if we ask > for the debugger, `condition-case` prevents the use of a debugger"? from the fact that the test (ert-deftest ert-test-error-debug () (let ((test (make-ert-test :body (lambda () (error "Error message"))))) (condition-case condition (progn (let ((ert-debug-on-error t)) (ert-run-test test)) (cl-assert nil)) ((error) (cl-assert (equal condition '(error "Error message")) t))))) explicitly tests that the handler for `error' sees the "Error message" (last 2 lines of the test), I'd also conjecture that tests intends to check that the debugger does not run in a condition-case. Also, a bit strange is that this: (ert-deftest ert-test-fail-debug-with-condition-case () (let ((test (make-ert-test :body (lambda () (ert-fail "failure message"))))) (condition-case condition (progn (let ((ert-debug-on-error t)) (ert-run-test test)) (cl-assert nil)) ((error) (cl-assert (equal condition '(ert-test-failed "failure message")) t))))) is almost the saem test? (Uses ert-fail instead of error). BTW, there are some more tests in the vicinity of the test above that test if the debugger is/isn't invoked in various circumstances. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 31 14:43:59 2023 Received: (at 67862-done) by debbugs.gnu.org; 31 Dec 2023 19:43:59 +0000 Received: from localhost ([127.0.0.1]:47059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rK1j4-0007oD-QZ for submit@debbugs.gnu.org; Sun, 31 Dec 2023 14:43:59 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1467) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rK1j2-0007nz-Ht for 67862-done@debbugs.gnu.org; Sun, 31 Dec 2023 14:43:56 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 62284442B0F; Sun, 31 Dec 2023 14:43:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704051824; bh=r64j61ynaOBVlnhFpRf9ADAARb/1ZvnDjUvGBqxcJVE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mdZLN6Dvnw94M6XiauoSHrE84gZNqEBSApQYiKwTCl556NV0oB+5aL91OkMYaNm6U K3OJhAzX06zJGJ3+isF7ZigMfvDOQU9SgUwjgQ5X5LCP/ICgRlY1lh3nlNrpBrLxDA IRaePzbRXLQEyYQx86C1wRhfjsQmCacpehrtMOXnuNE6V7w5LXQB94MMVWxrqQSaT0 g32Q/wVaqoQzWk2dw3w6x3TWx93myli1bCdG03u9d9kyiX+Pz0xTSXqzv4Se3ZVH/D OQk9xwU2nt0MPgvZaRtHc0WXIZkwOHe2wPA36MwxDz9qxekDZvZ9BK7B1AYFDbu2DP SIv0uDaiR2LaA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 07CC3442B18; Sun, 31 Dec 2023 14:43:44 -0500 (EST) Received: from alfajor (unknown [207.96.224.130]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DD7D712120B; Sun, 31 Dec 2023 14:43:43 -0500 (EST) From: Stefan Monnier To: Gerd =?windows-1252?Q?M=F6llmann?= Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug In-Reply-To: ("Gerd =?windows-1252?Q?M=F6ll?= =?windows-1252?Q?mann=22's?= message of "Tue, 26 Dec 2023 19:00:34 +0100") Message-ID: References: Date: Sun, 31 Dec 2023 14:43: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 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-Debbugs-Envelope-To: 67862-done Cc: 67862-done@debbugs.gnu.org, Christian Ohler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > BTW, there are some more tests in the vicinity of the test above that > test if the debugger is/isn't invoked in various circumstances. Thanks for helping me through this code. My conclusion is that the three tests that are broken by the use of `handler-bind` are "bad" tests in the sense that they tested for a behavior which corresponds to a failure of ERT (they verified that ERT's error-tracing infrastructure is rendered inoperable by a surrounding `condition-case`, which amounts to saying that ERT was not working correctly when called within a `condition-case`). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 01 00:56:57 2024 Received: (at 67862-done) by debbugs.gnu.org; 1 Jan 2024 05:56:57 +0000 Received: from localhost ([127.0.0.1]:47266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKBIH-0003xP-BY for submit@debbugs.gnu.org; Mon, 01 Jan 2024 00:56:57 -0500 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]:50483) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKBIE-0003x8-Jr for 67862-done@debbugs.gnu.org; Mon, 01 Jan 2024 00:56:55 -0500 Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-50e7ddd999bso5484362e87.1 for <67862-done@debbugs.gnu.org>; Sun, 31 Dec 2023 21:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704088607; x=1704693407; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=a6ifGBk069csjfh8ep6+lKoapVrkr9WA2FLEN9aj/5k=; b=CCk5x/KIy2mqzdJzJHvARgdg0V40hC95l70OdAbdjQjesa7yuqJ3dQpROImM9Ttwjw TIITNZoVW3+lxpiN8MdcPyOQO76ndLE0nhWZjtypxgcne9JDMayRU+D3I7UOHwsC0Wqr We1J8Upmc/Vh0evAmK4JNIVCTBUOVadn7rzb/KRKB7AfBKc6B14HVQhiGUqhL4oHCjvJ PbsJv+40AGPbqXaPO2ezPi4cjTdMvhzosjLn2XIRwVJt5Z6DDJHfg6Ssy6zRYBOMwXvY VYN5Sqoe1bciIuADbpxRNY6QK/+N69AECE+QQIhG5BskHY+P8h8o0BSIKCbv3jT1c207 Doxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704088607; x=1704693407; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=a6ifGBk069csjfh8ep6+lKoapVrkr9WA2FLEN9aj/5k=; b=b/uVmYn/pYoZC0iAjkeGuE16czui9who9+MDz5Qs8IDIZkA/n/M4kYvBK2jbXGYMkB 4zlZW7mogBS0AXWn95BaEafSaaNirWb6k9yNPyRmJlSb936RIhiq59kSAQ+sFaS7Ewj4 BZhCRQqR473xSurStUnCRKQrP1o0nvRmLAPRIw4M9Gfg7QwJpfFaSLlGyrvpUASoia66 7R9KOgP65GfPsQ4NZlalc6CIHwm1n5H73kxXs4ogsb98P6/lCoavwafpmXP3RY9IA6Xi 46XD0MEiHgYGump0LR3NSWthUD6rKiMUQ9JYd3/OX9AnOs3jlDyWMRzYUfhD7vHXvMQT 1o8g== X-Gm-Message-State: AOJu0Yz4XoM4EhJfq2rxP653VlnqzJuYZX5GU81VfTMZEzhE9xk5R5xO 3MaHDxeaXFygX0Vz12XtCP8xFfGqJQA= X-Google-Smtp-Source: AGHT+IEk408oljaFB+13u/lHZ84r93+VujGbHvFlm/YbmKtUATjoXTlrmf6BR7Ae5CPqe/FQs8D9wQ== X-Received: by 2002:a05:6512:110a:b0:50e:7b4d:8883 with SMTP id l10-20020a056512110a00b0050e7b4d8883mr6545639lfg.58.1704088606397; Sun, 31 Dec 2023 21:56:46 -0800 (PST) Received: from Pro.fritz.box (p4fe3ac5e.dip0.t-ipconnect.de. [79.227.172.94]) by smtp.gmail.com with ESMTPSA id a14-20020a50ff0e000000b0054d360bdfd6sm14381022edu.73.2023.12.31.21.56.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 31 Dec 2023 21:56:45 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug In-Reply-To: (Stefan Monnier's message of "Sun, 31 Dec 2023 14:43:43 -0500") References: Date: Mon, 01 Jan 2024 06:56:44 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67862-done Cc: 67862-done@debbugs.gnu.org, Christian Ohler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > My conclusion is that the three tests that are broken by the use of > `handler-bind` are "bad" tests in the sense that they tested for > a behavior which corresponds to a failure of ERT (they verified that > ERT's error-tracing infrastructure is rendered inoperable by > a surrounding `condition-case`, which amounts to saying that ERT was not > working correctly when called within a `condition-case`). That makes sense, yes. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 01 07:15:26 2024 Received: (at 67862-done) by debbugs.gnu.org; 1 Jan 2024 12:15:26 +0000 Received: from localhost ([127.0.0.1]:47434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKHCY-0004Wt-6S for submit@debbugs.gnu.org; Mon, 01 Jan 2024 07:15:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKHCW-0004Gr-9T for 67862-done@debbugs.gnu.org; Mon, 01 Jan 2024 07:15:25 -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 ) id 1rKHCO-00038t-L5; Mon, 01 Jan 2024 07:15:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=E5arNZkaFfB7vR4fhc4E0eL3sgUMNyQHb5D7kymnCM4=; b=jLlvacTqzWM7QspPAiqL jD77CAZlDMorS8Zlfo3rM8IMI2z7mOJxmwbrUKXJw1LM60d7achx7uU5A715ku67ec7vI/Yvo+c5g oLTq3HQA1BOJGwrTNitCmoNlv/0zCAYAedXC0b++OFX5cJE63QhGSqCD0R/Krl/mLF518oDsOFH6d oFujROiEdSTkxBBrBDDG7rN3vMFPWq6+/KgcNT3pG6Jatq+LGAmtpWzEb6ieYrRK5RW6l0ZBuTbQh f9kw5g2ScXNFJ1o65KNm5GPNfDDxGgZQl/e3K8lySWUkcELz6fNODNQ/AF+JrqHiHwkvEUnWeFYe2 p2/nz/xFiyOtQA==; Date: Mon, 01 Jan 2024 14:15:12 +0200 Message-Id: <83r0j11c8f.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Mon, 01 Jan 2024 06:56:44 +0100) Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67862-done Cc: 67862-done@debbugs.gnu.org, monnier@iro.umontreal.ca, ohler@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 67862-done@debbugs.gnu.org, Christian Ohler > From: Gerd Möllmann > Date: Mon, 01 Jan 2024 06:56:44 +0100 > > Stefan Monnier writes: > > > My conclusion is that the three tests that are broken by the use of > > `handler-bind` are "bad" tests in the sense that they tested for > > a behavior which corresponds to a failure of ERT (they verified that > > ERT's error-tracing infrastructure is rendered inoperable by > > a surrounding `condition-case`, which amounts to saying that ERT was not > > working correctly when called within a `condition-case`). > > That makes sense, yes. I wonder why should we leave these tests in the files, instead of removing them? What purpose does that serve? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 01 11:43:12 2024 Received: (at 67862-done) by debbugs.gnu.org; 1 Jan 2024 16:43:12 +0000 Received: from localhost ([127.0.0.1]:48660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKLNg-0006pj-8Z for submit@debbugs.gnu.org; Mon, 01 Jan 2024 11:43:12 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3693) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKLNd-0006pW-VC for 67862-done@debbugs.gnu.org; Mon, 01 Jan 2024 11:43:10 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 78B2A440C33; Mon, 1 Jan 2024 11:43:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704127381; bh=z6m0U/zMZ6aY8mxxngH9Iyo4n0xOI6/ID+bVy8YqXB8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=i+UnjoenQf/1DGuATfQlCVDA0TlgjVXLeZWIcXBM2VYWmiCOmEKkhwH6J3NIldXW1 Ja4ahCUnlhgJ1Yta4Fh+7VKOX9CEHHYb3RyA1lu8PtddxyRj/17yVRhOAieHa5ItUu z7OpV7LV5TBGQeRmXariJqRQxcIlVrWBYcFPjY3b2TbYHyZ/+C9Zrwne0PDIZO8BcD gqrVCBbsRZHoAP7znjsCPlbmMWHIvUK7WtD0h0LgeXLyz3SoWaT880Q+915o8xo7Hd IngpxcHRbtZsSzCJnUQ7oJUwsR7G2zncJxVZGvJSfLVEItnmga+iBmUsu/XgGklmJj KbOcunSwtijrw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 61115440396; Mon, 1 Jan 2024 11:43:01 -0500 (EST) Received: from alfajor (unknown [207.96.224.130]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 41C05120315; Mon, 1 Jan 2024 11:43:01 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug In-Reply-To: <83r0j11c8f.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 01 Jan 2024 14:15:12 +0200") Message-ID: References: <83r0j11c8f.fsf@gnu.org> Date: Mon, 01 Jan 2024 11:43: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 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-Debbugs-Envelope-To: 67862-done Cc: Gerd =?windows-1252?Q?M=F6llmann?= , 67862-done@debbugs.gnu.org, ohler@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I wonder why should we leave these tests in the files, instead of > removing them? What purpose does that serve? Agreed, I'll remove them. Stefan From unknown Sun Jun 22 11:45:33 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 30 Jan 2024 12:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 01 17:22:09 2024 Received: (at control) by debbugs.gnu.org; 1 Feb 2024 22:22:09 +0000 Received: from localhost ([127.0.0.1]:43294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVfRh-0005Nc-66 for submit@debbugs.gnu.org; Thu, 01 Feb 2024 17:22:09 -0500 Received: from mail-108-mta37.mxroute.com ([136.175.108.37]:33435) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVfRa-0005NK-Ro for control@debbugs.gnu.org; Thu, 01 Feb 2024 17:22:07 -0500 Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta37.mxroute.com (ZoneMTA) with ESMTPSA id 18d66c38f0f0003727.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 01 Feb 2024 22:21:48 +0000 X-Zone-Loop: 42191e4b5389df93319e059c2c85fa9ece79b99e6839 X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From:Sender: Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=zK3CH1C71A7mxOSxrxCnsa4yeZjl/o+N/p+k/P1rzgQ=; b=boWvlT8g8ZmPdFCcicM+X60zRM nCG1VNuwW9i5DR1+tCngrTPuYvA25iqZdYG47xNPAVXs4QTdlneTyHZ+Jz4z/dCpYsYLT9Cih8qXd e4gfqmkrTj4p+3J27mYzpkh3fbDevWqTg1Ikk18JDboj2TzfS7+bHonkMrec6e4YkWWSa+y7JVvpt QDPTcOa9RJzAHKDartMlqL0UGpo3crvnPvjJPwc1+JjusTUwfsu/SG5ePqdBdh+9Tw/22DtxILTOO CbQ0/Tbk4/DmIaCimeHEZebmNcmPo7zi7J2ZJCvD5Nn2f7obIKABPAWCROEmRclwc86QVyaoPPwHy WCe1lbfA==; From: "J.P." To: control@debbugs.gnu.org Subject: control message for bug #67862 Date: Thu, 01 Feb 2024 14:21:45 -0800 Message-ID: <874jerltae.fsf@neverwas.me> MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) unarchive 67862 quit From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 01 17:27:42 2024 Received: (at 67862) by debbugs.gnu.org; 1 Feb 2024 22:27:42 +0000 Received: from localhost ([127.0.0.1]:43309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVfX3-0005X3-On for submit@debbugs.gnu.org; Thu, 01 Feb 2024 17:27:42 -0500 Received: from mail-108-mta31.mxroute.com ([136.175.108.31]:39459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVfX1-0005Wt-Kx for 67862@debbugs.gnu.org; Thu, 01 Feb 2024 17:27:40 -0500 Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta31.mxroute.com (ZoneMTA) with ESMTPSA id 18d66c8b9f80003727.001 for <67862@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 01 Feb 2024 22:27:27 +0000 X-Zone-Loop: 8de62693e228119e90805c42ea9961af1cb5833a8443 X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JB9/6z8aIHry9rsDatUoaKa6jmR2CNHP/ATwQWWBalU=; b=bDD9VhfARAVhjlsHfQyZCRiqIW PwNVq/rij4Fa1RC/SV556sTdKj/pYygSrvo30+G83ctcQo9CP+MSZBmXUEs+yNKN6frdwqWgytwTx 0A2A0WmXExRLaGh6fK6iWWZ7qVj15kC+F/m5PeJ6hGccyTureLSrFBd4Io40l+Oc8eUDdCTDQy9jD K/I+E7eDcwFuKbmlQa0bYpvS09EvsRSy6t+s+1VW1sLskjVmqwNcmEROlSwJHIfW3enJoSJodt+Nc Js59FVJml75QZu1RELVWpsnUbdgqSRCr/XgRyskvPwoAQDIX56wfYDGn7n9tUlU/nY7A8GaJHCLZs Zb8wtLsA==; From: "J.P." To: Stefan Monnier Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug In-Reply-To: (Stefan Monnier's message of "Sat, 16 Dec 2023 19:37:14 -0500") References: Date: Thu, 01 Feb 2024 14:27:23 -0800 Message-ID: <87o7czkegk.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67862 Cc: 67862@debbugs.gnu.org, Christian Ohler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Stefan, Apologies if this is old news, but I think I've noticed a difference in ERT's behavior that may align with this feature's introduction. With a snippet like this somewhere in lisp/emacs-lisp/ert-tests.el: (ert-deftest my-baseline () (error "Done wrong")) (ert-deftest my-filter () (let ((proc (start-process "my-filter" (current-buffer) "sh" "-c" "for i in $(seq 99); do echo $i; sleep 0.01; done"))) (set-process-filter proc (lambda (_ string) (when (string-search "42" string) (error "Encountered bad value")))) (with-timeout (5 (ert-fail "Timed out")) (while (process-live-p proc) (accept-process-output nil 0.01))))) (ert-deftest my-timer () (run-at-time 0.2 nil (lambda () (error "Encountered a problem"))) (with-timeout (5 (ert-fail "Timed out")) (while (accept-process-output nil 5)))) Run $ make -C test SELECTOR=my-baseline lisp/emacs-lisp/ert-tests.log $ make -C test SELECTOR=my-filter lisp/emacs-lisp/ert-tests.log $ make -C test SELECTOR=my-timer lisp/emacs-lisp/ert-tests.log (For me, doing everything in one go, e.g., with SELECTOR='"my-.*"', doesn't complete on master, so the output below is from separate runs.) Old behavior ============ Prior to fe0f15dbc96 "ert.el: Use `handler-bind` to record backtraces" SELECTOR=my-baseline -*- mode: compilation; default-directory: "~/emacs/handler-bind/test/" -*- Compilation started at Thu Feb 1 14:00:41 make lisp/emacs-lisp/ert-tests.log ELC+ELN lisp/emacs-lisp/ert-tests.elc GEN lisp/emacs-lisp/ert-tests.log Running 1 tests (2024-02-01 14:00:45-0800, selector `my-baseline') Test my-baseline backtrace: error("Done wrong") (closure (ert--test-body-was-run t) nil (error "Done wrong") nil)() ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test ert-run-test(#s(ert-test :name my-baseline :documentation nil : ert-run-or-rerun-test(#s(ert--stats :selector my-baseline :test ert-run-tests(my-baseline #f(compiled-function (event-type &res ert-run-tests-batch(my-baseline) ert-run-tests-batch-and-exit(my-baseline) eval((ert-run-tests-batch-and-exit 'my-baseline) t) command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/emacs-lisp/ert-tests command-line() normal-top-level() Test my-baseline condition: (error "Done wrong") FAILED 1/1 my-baseline (0.000469 sec) at lisp/emacs-lisp/ert-tests.el:904 Ran 1 tests, 0 results as expected, 1 unexpected (2024-02-01 14:00:46-0800, 0.428006 sec) 1 unexpected results: FAILED my-baseline "Done wrong" make: *** [Makefile:181: lisp/emacs-lisp/ert-tests.log] Error 1 Compilation exited abnormally with code 2 at Thu Feb 1 14:00:46, duration 4.32 s SELECTOR=my-filter -*- mode: compilation; default-directory: "~/emacs/handler-bind/test/" -*- Compilation started at Thu Feb 1 14:03:54 make lisp/emacs-lisp/ert-tests.log ELC+ELN lisp/emacs-lisp/ert-tests.elc GEN lisp/emacs-lisp/ert-tests.log Running 1 tests (2024-02-01 14:03:58-0800, selector `my-filter') Test my-filter backtrace: error("Encountered bad value") (progn (error "Encountered bad value")) (if (string-search "42" string) (progn (error "Encountered bad value (closure (t) (_ string) (if (string-search "42" string) (progn (erro accept-process-output(nil 0.01) (while (process-live-p proc) (accept-process-output nil 0.01)) (progn (while (process-live-p proc) (accept-process-output nil 0.01) (unwind-protect (progn (while (process-live-p proc) (accept-process- (let* ((-with-timeout-timer- (run-with-timer 5 nil #'(lambda nil (th (catch 'timeout (let* ((-with-timeout-timer- (run-with-timer 5 nil # (let ((-with-timeout-value- (catch 'timeout (let* ((-with-timeout-ti (let ((proc (start-process "my-filter" (current-buffer) "sh" "-c" "f (closure (ert--test-body-was-run t) nil (let ((proc (start-process " ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test ert-run-test(#s(ert-test :name my-filter :documentation nil :body (c ert-run-or-rerun-test(#s(ert--stats :selector my-filter :tests [#s(e ert-run-tests(my-filter #f(compiled-function (event-type &rest event ert-run-tests-batch(my-filter) ert-run-tests-batch-and-exit(my-filter) eval((ert-run-tests-batch-and-exit 'my-filter) t) command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/emacs-lisp/ert-tests command-line() normal-top-level() Test my-filter condition: (error "Encountered bad value") FAILED 1/1 my-filter (0.476963 sec) at lisp/emacs-lisp/ert-tests.el:907 Ran 1 tests, 0 results as expected, 1 unexpected (2024-02-01 14:03:59-0800, 1.204823 sec) 1 unexpected results: FAILED my-filter "Encountered bad value" make: *** [Makefile:181: lisp/emacs-lisp/ert-tests.log] Error 1 Compilation exited abnormally with code 2 at Thu Feb 1 14:03:59, duration 5.12 s SELECTOR=my-timer -*- mode: compilation; default-directory: "~/emacs/handler-bind/test/" -*- Compilation started at Thu Feb 1 14:04:46 make lisp/emacs-lisp/ert-tests.log GEN lisp/emacs-lisp/ert-tests.log Running 1 tests (2024-02-01 14:04:47-0800, selector `my-timer') Test my-timer backtrace: error("Encountered a problem") (closure (ert--test-body-was-run t) nil (error "Encountered a proble apply((closure (ert--test-body-was-run t) nil (error "Encountered a timer-event-handler([t 26044 5504 133541 nil (closure (ert--test-bod accept-process-output(nil 5) (while (accept-process-output nil 5)) (progn (while (accept-process-output nil 5))) (unwind-protect (progn (while (accept-process-output nil 5))) (cance (let* ((-with-timeout-timer- (run-with-timer 5 nil #'(lambda nil (th (catch 'timeout (let* ((-with-timeout-timer- (run-with-timer 5 nil # (let ((-with-timeout-value- (catch 'timeout (let* ((-with-timeout-ti (closure (ert--test-body-was-run t) nil (run-at-time 0.2 nil #'(lamb ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test ert-run-test(#s(ert-test :name my-timer :documentation nil :body (cl ert-run-or-rerun-test(#s(ert--stats :selector my-timer :tests [#s(er ert-run-tests(my-timer #f(compiled-function (event-type &rest event- ert-run-tests-batch(my-timer) ert-run-tests-batch-and-exit(my-timer) eval((ert-run-tests-batch-and-exit 'my-timer) t) command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/emacs-lisp/ert-tests command-line() normal-top-level() Test my-timer condition: (error "Encountered a problem") FAILED 1/1 my-timer (0.201019 sec) at lisp/emacs-lisp/ert-tests.el:919 Ran 1 tests, 0 results as expected, 1 unexpected (2024-02-01 14:04:48-0800, 0.701159 sec) 1 unexpected results: FAILED my-timer "Encountered a problem" make: *** [Makefile:181: lisp/emacs-lisp/ert-tests.log] Error 1 Compilation exited abnormally with code 2 at Thu Feb 1 14:04:48, duration 1.86 s New behavior ============ HEAD happens to at 71b5d5a9799 "; Fix typos" SELECTOR=my-baseline -*- mode: compilation; default-directory: "~/emacs/master/test/" -*- Compilation started at Thu Feb 1 13:54:48 make lisp/emacs-lisp/ert-tests.log ELC+ELN lisp/emacs-lisp/ert-tests.elc GEN lisp/emacs-lisp/ert-tests.log Running 1 tests (2024-02-01 13:54:52-0800, selector `my-baseline') Test my-baseline backtrace: error("Done wrong") (closure (ert--test-body-was-run t) nil (error "Done wrong") nil)() #f(compiled-function () #)() handler-bind-1(#f(compiled-function () # ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test ert-run-test(#s(ert-test :name my-baseline :documentation nil : ert-run-or-rerun-test(#s(ert--stats :selector my-baseline :test ert-run-tests(my-baseline #f(compiled-function (event-type &res ert-run-tests-batch(my-baseline) ert-run-tests-batch-and-exit(my-baseline) eval((ert-run-tests-batch-and-exit 'my-baseline) t) command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/emacs-lisp/ert-tests command-line() normal-top-level() Test my-baseline condition: (error "Done wrong") FAILED 1/1 my-baseline (0.000371 sec) at lisp/emacs-lisp/ert-tests.el:879 Ran 1 tests, 0 results as expected, 1 unexpected (2024-02-01 13:54:52-0800, 0.495511 sec) 1 unexpected results: FAILED my-baseline "Done wrong" make: *** [Makefile:181: lisp/emacs-lisp/ert-tests.log] Error 1 Compilation exited abnormally with code 2 at Thu Feb 1 13:54:52, duration 4.49 s SELECTOR=my-filter -*- mode: compilation; default-directory: "~/emacs/master/test/" -*- Compilation started at Thu Feb 1 13:55:59 make lisp/emacs-lisp/ert-tests.log GEN lisp/emacs-lisp/ert-tests.log Running 1 tests (2024-02-01 13:56:00-0800, selector `my-filter') error in process filter: Encountered bad value make: *** [Makefile:181: lisp/emacs-lisp/ert-tests.log] Error 255 Compilation exited abnormally with code 2 at Thu Feb 1 13:56:01, duration 1.69 s SELECTOR=my-timer Running 1 tests (2024-02-01 13:56:46-0800, selector `my-timer') Error running timer: (error "Encountered a problem") passed 1/1 my-timer (5.005249 sec) Ran 1 tests, 1 results as expected, 0 unexpected (2024-02-01 13:56:51-0800, 5.005712 sec) I suppose folks who prefer a backtrace can always wrap their filters and timers in their own `handler-bind' forms, but the premature exit thing would seem to affect anything that greps the output for well known indicators, like "FAILED". These might include tests that spawn other tests and external scripts. Anyway, thanks a lot for adding this feature. It should prove quite useful to ERC. J.P. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 01 21:46:57 2024 Received: (at 67862) by debbugs.gnu.org; 2 Feb 2024 02:46:58 +0000 Received: from localhost ([127.0.0.1]:43389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVjZx-0007Nz-HU for submit@debbugs.gnu.org; Thu, 01 Feb 2024 21:46:57 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4254) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVjZs-0007Ni-0f for 67862@debbugs.gnu.org; Thu, 01 Feb 2024 21:46:56 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7E0301003D2; Thu, 1 Feb 2024 21:46:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706841994; bh=kH97s4wtVtR3tKYBPlKzDQmlfCrqd22zhfxtYYSvp8k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=o+u02cADX/95O/Pz1Vp2C3nNe7BJOx418QLEYqHEaBF49hr/pauJ6IqOcR2jQH6Tg 25E8zQyLMS8/zCDmCk7xVRForfg7gNzQmvPYokEA4i3h+0HgHgp31I2ekW7MlF73am 0hzxRNIDdnNsaYSpA9pIs+keLHWJACoFvZAilzCQgZQxt8w8f5qIC2Gc2QrQ0H1V57 3yCgMwYJHKU2oV4pEyHC3H/bl3EoPA9OxTvDZv3zsUPXao/0RiyI5LZkdQ02fBGGXT e0ddVX4iwOlYTSrd2Z7WvOPvQfxbpcGd2ul6BI+80++sSELzBCBaxsi6AQdCCplNBB /GsaBdIwWF0ww== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5395D1003AF; Thu, 1 Feb 2024 21:46:34 -0500 (EST) Received: from pastel (69-165-153-17.dsl.teksavvy.com [69.165.153.17]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2539612025D; Thu, 1 Feb 2024 21:46:34 -0500 (EST) From: Stefan Monnier To: "J.P." Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug In-Reply-To: <87o7czkegk.fsf@neverwas.me> (J. P.'s message of "Thu, 01 Feb 2024 14:27:23 -0800") Message-ID: References: <87o7czkegk.fsf@neverwas.me> Date: Thu, 01 Feb 2024 21:46:32 -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 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-Debbugs-Envelope-To: 67862 Cc: 67862@debbugs.gnu.org, Christian Ohler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi J.P., > (ert-deftest my-baseline () > (error "Done wrong")) > > (ert-deftest my-filter () > (let ((proc > (start-process "my-filter" (current-buffer) "sh" "-c" > "for i in $(seq 99); do echo $i; sleep 0.01; done"))) > (set-process-filter proc > (lambda (_ string) > (when (string-search "42" string) > (error "Encountered bad value")))) > (with-timeout (5 (ert-fail "Timed out")) > (while (process-live-p proc) > (accept-process-output nil 0.01))))) > > (ert-deftest my-timer () > (run-at-time 0.2 nil (lambda () (error "Encountered a problem"))) > (with-timeout (5 (ert-fail "Timed out")) > (while (accept-process-output nil 5)))) Thanks. Indeed, `handler-bind` behaves differently than `debug-on-error` here. The reason is: - For `my-filter`, process.c:6329 it's the `!NILP (Vdebug_on_error)` test in: internal_condition_case_1 (read_process_output_call, list3 (outstream, make_lisp_proc (p), text), !NILP (Vdebug_on_error) ? Qnil : Qerror, read_process_output_error_handler); - For `my-timer`, it's the `condition-case-unless-debug` in timer.el:319: (condition-case-unless-debug err ;; Timer functions should not change the current buffer. ;; If they do, all kinds of nasty surprises can happen, ;; and it can be hellish to track down their source. (save-current-buffer (apply (timer--function timer) (timer--args timer))) (error (message "Error running timer%s: %S" (if (symbolp (timer--function timer)) (format-message " `%s'" (timer--function timer)) "") err))) The reason to catch errors in those two cases is that these codes are normally run asynchronously, so it makes sense to catch errors rather than propagate them up to some unrelated ambient code being executed. For `my-filter` I can see a good argument that errors should be propagated when you pass `proc` explicitly to `accept-process-output` and the filter/sentinel that signals the error is indeed this very process: in that case, there is a very clear connection between the filter/sentinel and the ambient code which would justify propagating the error. For `my-timer`, on the other hand, hmm... Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 02 18:28:37 2024 Received: (at 67862) by debbugs.gnu.org; 2 Feb 2024 23:28:37 +0000 Received: from localhost ([127.0.0.1]:45660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rW2xY-0008Bs-Nb for submit@debbugs.gnu.org; Fri, 02 Feb 2024 18:28:37 -0500 Received: from mail-108-mta94.mxroute.com ([136.175.108.94]:40491) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rW2xW-0008Bi-9g for 67862@debbugs.gnu.org; Fri, 02 Feb 2024 18:28:35 -0500 Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta94.mxroute.com (ZoneMTA) with ESMTPSA id 18d6c26d52b0003727.001 for <67862@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 02 Feb 2024 23:28:20 +0000 X-Zone-Loop: c6af112d8b5d2ae530fac81ed1f0dcc51106b02b15fc X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=U1dzNrSU6iYjDdOlO2hG9Q2Gk86uqFzcaShRuqeDlE8=; b=HjK+K3lcBSTcOR+unOaowb7NvB T4yLzd6eExv2wF3CBl1R8rSeYNakb/yh9AR6Dz08eOJXNKGx7sFh6wuWc2OWLcMj5wuCytRBghDej oMHdI7QTBcP5w+xiGOrZghEMdcTphSYYuT800EI4MODMmUuW4b8GVoLOWEGCqtJZhsqp2cZODfnXw vqy81WOm3b9ZNPzHPeYKWFTnY7qfSEMpHK9EzSfBzgSV3/KIsqt1u5jxL1emmTh401gk3NgjVP3eb 83Q5nX2jV3T6HTQylyd572pxjMiiqaiiuhodi4KU5NFfYtiI2Hov3s2osMlNci+dFjjd9Hjr2jgVY AtK5KppA==; From: "J.P." To: Stefan Monnier Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug In-Reply-To: (Stefan Monnier's message of "Thu, 01 Feb 2024 21:46:32 -0500") References: <87o7czkegk.fsf@neverwas.me> Date: Fri, 02 Feb 2024 15:28:12 -0800 Message-ID: <87ttmqh2er.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67862 Cc: 67862@debbugs.gnu.org, Christian Ohler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > - For `my-filter`, process.c:6329 it's the `!NILP (Vdebug_on_error)` test in: > > internal_condition_case_1 (read_process_output_call, > list3 (outstream, make_lisp_proc (p), text), > !NILP (Vdebug_on_error) ? Qnil : Qerror, > read_process_output_error_handler); > > - For `my-timer`, it's the `condition-case-unless-debug` in timer.el:319: > > (condition-case-unless-debug err > ;; Timer functions should not change the current buffer. > ;; If they do, all kinds of nasty surprises can happen, > ;; and it can be hellish to track down their source. > (save-current-buffer > (apply (timer--function timer) (timer--args timer))) > (error (message "Error running timer%s: %S" > (if (symbolp (timer--function timer)) > (format-message " `%s'" (timer--function timer)) > "") > err))) > > The reason to catch errors in those two cases is that these codes are > normally run asynchronously, so it makes sense to catch errors rather > than propagate them up to some unrelated ambient code being executed. > > For `my-filter` I can see a good argument that errors should be > propagated when you pass `proc` explicitly to `accept-process-output` > and the filter/sentinel that signals the error is indeed this very > process: in that case, there is a very clear connection between the > filter/sentinel and the ambient code which would justify propagating > the error. Appreciate the insight re `debug-on-error'. Indeed, running `my-filter' with the variable enabled regains the original behavior WRT the backtrace, the summary, and the exit code. And I suppose those worried about such details (like ERC's bot, which depends on JUnit reports from EMBA pipelines) can just enable it themselves. > > For `my-timer`, on the other hand, hmm... For this one, enabling `debug-on-error' at least seems to restore the original behavior in terms of exiting nonzero, which should free users from having to grep for "Error running timer" in the output of passing tests. -*- mode: compilation; default-directory: "~/emacs/master/test/" -*- Compilation started at Fri Feb 2 14:51:58 make lisp/emacs-lisp/ert-tests.log ELC+ELN lisp/emacs-lisp/ert-tests.elc GEN lisp/emacs-lisp/ert-tests.log Running 1 tests (2024-02-02 14:52:02-0800, selector `my-timer') Debugger entered--Lisp error: (error "Encountered a problem") error("Encountered a problem") (closure (ert--test-body-was-run t) nil (error "Encountered a problem"))() apply((closure (ert--test-body-was-run t) nil (error "Encountered a problem")) nil) [...] ert-run-tests-batch(my-timer) ert-run-tests-batch-and-exit(my-timer) eval((ert-run-tests-batch-and-exit 'my-timer) t) command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/emacs-lisp/ert-tests.el" "--eval" "(ert-run-tests-batch-and-exit (quote my-timer))")) command-line() normal-top-level() make: *** [Makefile:181: lisp/emacs-lisp/ert-tests.log] Error 255 Compilation exited abnormally with code 2 at Fri Feb 2 14:52:02, duration 4.30 s I guess folks who depend on these always running to completion will still have to adapt a bit, but in light of this workaround, I'd say these changes are much less disruptive than originally feared, which is a welcome relief. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 02 18:44:58 2024 Received: (at 67862) by debbugs.gnu.org; 2 Feb 2024 23:44:58 +0000 Received: from localhost ([127.0.0.1]:45673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rW3DO-0000AS-1r for submit@debbugs.gnu.org; Fri, 02 Feb 2024 18:44:58 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rW3DL-0000AB-Q8 for 67862@debbugs.gnu.org; Fri, 02 Feb 2024 18:44:56 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A77FC1003E3; Fri, 2 Feb 2024 18:44:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706917476; bh=qzsAqMGQbdDOgMZ/2haoQZQCDHkBqcBKRRV3FBvEfDw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZmExp7HSnJ7IuhL30fRWMSjXCzE3cpfhFGZaMMCGJqCn6Oznf1zGy/M5mCExbKzaV jyNUOsKNy9rjedWc16/muriwZ6W/jfU2hLOny7VBiQMjQ9xfMhp2EsQxKILqQGlL5l HdptUjzQhxgGqEmQ5MfsKNa/zMbi96CYjJ/xzu/GNJPpwUXNKQ3+CtfZDti59+xKwv AXYU3Oe6JWy+eCHL5ZWjUKmjm/5T7sLDKJujnnxVq5Hk4UIEF9yspWh21Jof0souDq 1quE5P1jrifwBGpUObZJmftzYPqagaC4LnF6SK8MwRTq3XLStp13/h2jO5A4mciq41 U2xEVNMpvj+Xw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9AF451003BC; Fri, 2 Feb 2024 18:44:36 -0500 (EST) Received: from pastel (69-165-153-17.dsl.teksavvy.com [69.165.153.17]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7253C120387; Fri, 2 Feb 2024 18:44:36 -0500 (EST) From: Stefan Monnier To: "J.P." Subject: Re: bug#67862: 30.0.50; Handler-bind and ert-test-error-debug In-Reply-To: <87ttmqh2er.fsf@neverwas.me> (J. P.'s message of "Fri, 02 Feb 2024 15:28:12 -0800") Message-ID: References: <87o7czkegk.fsf@neverwas.me> <87ttmqh2er.fsf@neverwas.me> Date: Fri, 02 Feb 2024 18:44:35 -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.415 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-Debbugs-Envelope-To: 67862 Cc: 67862@debbugs.gnu.org, Christian Ohler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> For `my-timer`, on the other hand, hmm... > > For this one, enabling `debug-on-error' at least seems to restore the > original behavior in terms of exiting nonzero, which should free users > from having to grep for "Error running timer" in the output of passing > tests. Not getting a backtrace, or ERT not noticing that there was an error is "normal": which errors are detected and which aren't is subtly different and it's hard to argue that the old way was better (it has upsides and downsides). But inf-looping definitely counts as a bug in my book (since the `with-timeout` should rule it out) and I don't have an explanation for it. Any help debugging it would be welcome. Stefan From unknown Sun Jun 22 11:45:33 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 02 Mar 2024 12:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator