From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors. Date: Mon, 4 Nov 2024 21:08:35 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13570"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 66912@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 04 22:10:52 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1t84Lc-0003Is-4d for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Nov 2024 22:10:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t84Jx-0008Dz-G1; Mon, 04 Nov 2024 16:09:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t84Jq-0007yX-JY for bug-gnu-emacs@gnu.org; Mon, 04 Nov 2024 16:09:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t84Jq-0005W2-9Q for bug-gnu-emacs@gnu.org; Mon, 04 Nov 2024 16:09:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=From:In-Reply-To:MIME-Version:References:Date:To:Subject; bh=lrXGrt6qxd8yN8dYDnOU2oCn3sCL/qxic3/t5gMmVO4=; b=TgEIEFVIY+9Um32XFFCq+im8nFDHTldSLHGna+MePkWIwqGfvTl5KaT36+EkzMZyE/Tsev2+n7dYK4zXQi+1mPWqEg9X9hRxLPgIOcwSPPOjA5Zb+9ZXpreeNQpYzfJ8AvVspIHKqd2OsSRUdznVEs6youE0ZafUlf1h+uci5NGReEGeIzSL9TOX6T9lqZjpx4Te37yFX7segqUFSSXxh4k3BOTx7THxQpFHvpQ/wu6P6eH1UORlFBhGUTPas8FJeeVeoxNfZnjJzRv83LSK9ailpHoE7rFhQg9skdYj+AHUfZBoOi2BJD82u005d25vRAf37qjmSY2I3R0etPGWHg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t84Jq-0001A0-34 for bug-gnu-emacs@gnu.org; Mon, 04 Nov 2024 16:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Nov 2024 21:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66912 X-GNU-PR-Package: emacs Original-Received: via spool by 66912-submit@debbugs.gnu.org id=B66912.17307545274452 (code B ref 66912); Mon, 04 Nov 2024 21:09:02 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 4 Nov 2024 21:08:47 +0000 Original-Received: from localhost ([127.0.0.1]:42343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t84Ja-00019i-FL for submit@debbugs.gnu.org; Mon, 04 Nov 2024 16:08:47 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:41794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t84JY-00019a-GM for 66912@debbugs.gnu.org; Mon, 04 Nov 2024 16:08:45 -0500 Original-Received: (qmail 28059 invoked by uid 3782); 4 Nov 2024 22:08:36 +0100 Original-Received: from muc.de (p4fe1531c.dip0.t-ipconnect.de [79.225.83.28]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 04 Nov 2024 22:08:36 +0100 Original-Received: (qmail 14886 invoked by uid 1000); 4 Nov 2024 21:08:35 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:294885 Archived-At: Hello, Stefan. On Mon, Nov 04, 2024 at 11:12:19 -0500, Stefan Monnier wrote: > >> I don't understand the above code: `handler-bind` is not supposed to > >> call setjmp/longjmp: when the handler of a `handler-bind` gets called, > >> the stack is not unwound. > > I started off by just making the HANDLER_BIND case use the same code as > > CONDITION_CASE, and got segfaults. I've tried to find the places where > > a longjmp gets called for condition-case, but my brain's tired after a > > weekend of heavy coding. > The longjmp is in `unwind_to_catch`, called from `signal_or_quit`, but > we only get there for CONDITION_CASE, not for HANDLER_BIND. OK, thanks. > > Given HANDLER_BIND doesn't need the setjmp/longjmp mechanism, it would > > seem there's no sense in combining the HANDLER_BIND and CONDITION_CASE > > cases in internal_cc_hb and friends. I should just restore the > > condition-case functions to what they were, and add separate new ones > > for handler-bind. > OK. DONE. > > I think I see now you're right. push_handler doesn't push an entry onto > > the binding stack. I'll amend these comments as soon as I understand > > the code. I think these lines definitely need comments. > Maybe pointing the reader to the SKIP_CONDITIONS comment in `lisp.h`? I've put a brief comment on the line saying /* Restore after `max_ensure_room'. */ > >> Also there's no reason to presume the HANDLER_BIND handler is at the > >> top, so if we wanted to remove it, we'd have to work harder. > > This code is difficult to understand. What is the purpose of the > > binding block around the call of the handler function? I think a > > comment here would help. > The `unbind_to` is there because `max_ensure_room` may > `specbind` something. In 99% of the cases it does nothing. OK, thanks, I've got that. > >> How is this related to `Fprefix_load_file_names`? > > Not closely. I think I should have propsed two separate patches, rather > > than the big one I did. Fprefix_load_file_names is what puts the "While > > loading foo.el... " in front of an error message. > Splitting it into two would be good yes. OK, I think I agree, even if I would rather not have to advocate for the second patch again. ;-) > AFAICT, the `Fprefix_load_file_names` is the part that aims to address > bug#66912. IMO the other belongs in another bug-report/feature-request? OK, I've separated out the bit that applies "While loading foo.el... " from all the stuff about handler-bind. The patch below should, on its own, fix bug#66912. What's not there yet is being able to get into the debugger when a byte compilation is requiring a file, and debug-on-error has been set. That will be the subject of the next bug report. Here's the amended patch. It's a lot shorter (and easier) than the previous version. I would like to commit it as the fix to bug#66912. diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index f058fc48cc7..776083468c6 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -1436,8 +1436,9 @@ byte-compile-report-error when printing the error message." (setq byte-compiler-error-flag t) (byte-compile-log-warning - (if (stringp error-info) error-info - (error-message-string error-info)) + (prefix-load-file-names + (if (stringp error-info) error-info + (error-message-string error-info))) fill :error)) ;;; sanity-checking arglists diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el index ec947c1215d..4068daf6614 100644 --- a/lisp/emacs-lisp/debug.el +++ b/lisp/emacs-lisp/debug.el @@ -418,7 +418,9 @@ debugger--insert-header ;; Debugger entered for an error. ('error (insert "--Lisp error: ") - (insert (backtrace-print-to-string (nth 1 args))) + (insert + (prefix-load-file-names + (backtrace-print-to-string (nth 1 args)))) (insert ?\n)) ;; debug-on-call, when the next thing is an eval. ('t @@ -426,8 +428,10 @@ debugger--insert-header ;; User calls debug directly. (_ (insert ": ") - (insert (backtrace-print-to-string (if (eq (car args) 'nil) - (cdr args) args))) + (insert + (prefix-load-file-names + (backtrace-print-to-string (if (eq (car args) 'nil) + (cdr args) args)))) (insert ?\n)))) diff --git a/src/keyboard.c b/src/keyboard.c index 6d28dca9aeb..6758c328038 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -1096,7 +1096,7 @@ DEFUN ("command-error-default-function", Fcommand_error_default_function, Fdiscard_input (); bitch_at_user (); } - + context = Fprefix_load_file_names (context); print_error_message (data, Qt, SSDATA (context), signal); } return Qnil; diff --git a/src/lread.c b/src/lread.c index ea0398196e3..f81efb3df70 100644 --- a/src/lread.c +++ b/src/lread.c @@ -236,6 +236,9 @@ #define USE_ANDROID_ASSETS check for recursive loads. */ static Lisp_Object Vloads_in_progress; +/* The same as the above, except it survives the unbinding done in the + event of an error, and can thus be used in error handling. */ +Lisp_Object Vloads_still_in_progress; static int read_emacs_mule_char (int, int (*) (int, Lisp_Object), Lisp_Object); @@ -1271,6 +1274,29 @@ close_file_unwind_android_fd (void *ptr) #endif +DEFUN ("prefix-load-file-names", Fprefix_load_file_names, + Sprefix_load_file_names, 1, 1, 0, + doc: /* Prefix the string BASE_STRING with a message about each +file currently being loaded. Return the resulting string and reset this +information to null. */) + (Lisp_Object base_string) +{ + Lisp_Object result = build_string (""); + Lisp_Object while_loading = build_string ("While loading "); + Lisp_Object ellipsis = build_string ("... "); + + while (!NILP (Vloads_still_in_progress)) + { + result = concat2 (concat3 (while_loading, + Fcar (Vloads_still_in_progress), + ellipsis), + result); + Vloads_still_in_progress = Fcdr (Vloads_still_in_progress); + } + result = concat3 (result, build_string ("\n"), base_string); + return result; +} + DEFUN ("load", Fload, Sload, 1, 5, 0, doc: /* Execute a file of Lisp code named FILE. First try FILE with `.elc' appended, then try with `.el', then try @@ -1516,6 +1542,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0, signal_error ("Recursive load", Fcons (found, Vloads_in_progress)); record_unwind_protect (record_load_unwind, Vloads_in_progress); Vloads_in_progress = Fcons (found, Vloads_in_progress); + Vloads_still_in_progress = Vloads_in_progress; } /* All loads are by default dynamic, unless the file itself specifies @@ -1615,7 +1642,9 @@ DEFUN ("load", Fload, Sload, 1, 5, 0, val = call4 (Vload_source_file_function, found, hist_file_name, NILP (noerror) ? Qnil : Qt, (NILP (nomessage) || force_load_messages) ? Qnil : Qt); - return unbind_to (count, val); + unbind_to (count, Qnil); + Vloads_still_in_progress = Vloads_in_progress; + return val; } } @@ -1741,6 +1770,8 @@ DEFUN ("load", Fload, Sload, 1, 5, 0, if (!NILP (Ffboundp (Qdo_after_load_evaluation))) call1 (Qdo_after_load_evaluation, hist_file_name) ; + Vloads_still_in_progress = Vloads_in_progress; + for (int i = 0; i < ARRAYELTS (saved_strings); i++) { xfree (saved_strings[i].string); @@ -5772,6 +5803,7 @@ init_lread (void) Vload_true_file_name = Qnil; Vstandard_input = Qt; Vloads_in_progress = Qnil; + Vloads_still_in_progress = Qnil; } /* Print a warning that directory intended for use USE and with name @@ -5819,6 +5851,7 @@ syms_of_lread (void) defsubr (&Sintern_soft); defsubr (&Sunintern); defsubr (&Sget_load_suffixes); + defsubr (&Sprefix_load_file_names); defsubr (&Sload); defsubr (&Seval_buffer); defsubr (&Seval_region); @@ -6138,6 +6171,8 @@ syms_of_lread (void) Vloads_in_progress = Qnil; staticpro (&Vloads_in_progress); + Vloads_still_in_progress = Qnil; + staticpro (&Vloads_still_in_progress); DEFSYM (Qhash_table, "hash-table"); DEFSYM (Qdata, "data"); > Stefan -- Alan Mackenzie (Nuremberg, Germany).