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 12:52:10 +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="2797"; 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 13:53:23 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 1t7waA-0000U2-L5 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Nov 2024 13:53:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t7wa0-0004AC-7t; Mon, 04 Nov 2024 07:53:12 -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 1t7wZs-00047C-HW for bug-gnu-emacs@gnu.org; Mon, 04 Nov 2024 07:53:06 -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 1t7wZr-0003tJ-Vm for bug-gnu-emacs@gnu.org; Mon, 04 Nov 2024 07:53:04 -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=PVfkWoC/4o+H8f77cWvw89dyivOF1mpCjDpTkAZ6jNs=; b=fSoSdEYpRYMn2+yBJ6gCV6CKQJywdmgz5I9vEvLnyA4cj8HKYUT7KiFeLZJtHN2vFwhxk7Yr0Vpx9sqyACkzIAE3TzybgRMbtNp0rDKHiaF/Jx+05I6tm92iXy845jrJIU4+ZmjvoLHg6oN/SQ9C3qcJ9XwNKJJJp7KVAysOBE50QFBS6XZn4ERbBnT4cf8saTDJ93KHFkEjHDZoL8NRf6bLtbmFFyrPtHecgAhyi6x9bUAVZYfL092eUXerENGiGWcLS2Xo0aPNDL+6yrQPUE6TS3h0RHJaC16J6A5+ZMFp4u5NWgC5Ofu2XSZtsTb7RelkwzZK9r/wQYe9uJrvsw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t7wZq-0001f6-IE for bug-gnu-emacs@gnu.org; Mon, 04 Nov 2024 07:53: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 12:53: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.17307247426362 (code B ref 66912); Mon, 04 Nov 2024 12:53:02 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 4 Nov 2024 12:52:22 +0000 Original-Received: from localhost ([127.0.0.1]:39670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7wZB-0001eY-Mo for submit@debbugs.gnu.org; Mon, 04 Nov 2024 07:52:22 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:41047) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7wZ8-0001eM-MS for 66912@debbugs.gnu.org; Mon, 04 Nov 2024 07:52:20 -0500 Original-Received: (qmail 54737 invoked by uid 3782); 4 Nov 2024 13:52:11 +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 13:52:11 +0100 Original-Received: (qmail 5705 invoked by uid 1000); 4 Nov 2024 12:52:10 -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:294848 Archived-At: Hello, Stefan. Thanks for such a rapid response! On Sun, Nov 03, 2024 at 21:46:42 -0500, Stefan Monnier wrote: > Hi Alan, > I couldn't properly review your code because I had trouble > understanding it. So instead, it's mostly questions. > > +static Lisp_Object > > +internal_cc_hb (enum handlertype handlertype, > > + Lisp_Object (*bfun) (void), Lisp_Object handlers, > > + Lisp_Object (*hfun) (Lisp_Object)) > > +{ > > + struct handler *c = push_handler (handlers, handlertype); > > + > > + if (handlertype == HANDLER_BIND) > > + { > > + c->val = Qnil; > > + c->bin_handler = hfun; > > + c->bytecode_dest = 0; > > + } > > + if (sys_setjmp (c->jmp)) > > + { > > + Lisp_Object val = handlerlist->val; > > + clobbered_eassert (handlerlist == c); > > + handlerlist = handlerlist->next; > > + return hfun (val); > > + } > > + else > > + { > > + Lisp_Object val = bfun (); > > + eassert (handlerlist == c); > > + handlerlist = c->next; > > + return val; > > + } > > +} > I don't understand the above code: `handler-bind` is not supposed to > call setjmp/longjmp: when the handler of a `handler-bind` gets called, > the stack is not unwound. I started off by just making the HANDLER_BIND case use the same code as CONDITION_CASE, and got segfaults. I've tried to find the places where a longjmp gets called for condition-case, but my brain's tired after a weekend of heavy coding. Given HANDLER_BIND doesn't need the setjmp/longjmp mechanism, it would seem there's no sense in combining the HANDLER_BIND and CONDITION_CASE cases in internal_cc_hb and friends. I should just restore the condition-case functions to what they were, and add separate new ones for handler-bind. > So what is the `sys_setjmp` for when `handlertype == HANDLER_BIND`? After reading your previous paragraph, probably nothing. [ .... ] > [ We don't need parens around `h->bin_handler`. ] They've gone. > > + else > > + call1 (h->val, error); > > + unbind_to (count, Qnil); /* Removes SKIP_CONDITIONS handler. */ > > + pop_handler (); /* Discards HANDLER_BIND handler. */ > These comments don't match my understanding of the code: IIRC the > `pop_handler` pops the `SKIP_CONDITIONS` handler. I think I see now you're right. push_handler doesn't push an entry onto the binding stack. I'll amend these comments as soon as I understand the code. I think these lines definitely need comments. > Also there's no reason to presume the HANDLER_BIND handler is at the > top, so if we wanted to remove it, we'd have to work harder. This code is difficult to understand. What is the purpose of the binding block around the call of the handler function? I think a comment here would help. > > +/* Handle errors signalled by the above function. */ > > +static Lisp_Object > > +rel_error_handler (Lisp_Object err) > > +{ > > + if (!NILP (Vdebug_on_error)) > > + { > > + call_debugger (err); > > + Fthrow (Qtop_level, Qt); > > + } > > + else > > + return err; > > +} > I don't understand that. > AFAICT, this is the only HANDLER_BIND handler you install from > C code, right? So this is the thing that motivates all the changes like > `internal_cc_hb`, etc... so clearly it must do something worthwhile, but > I don't see what it is. rel_error_handler is currently the only such handler, yes. All this code (once it's debugged) will fix the inconsistency that condition-case, unwind-protect, catch and throw, ... can all be used from C code, but handler-bind can't be. rel_error_handler, in particular, allows the debugger to be called regardless of any active condition_cases which would otherwise block it. In the byte compiler, there is such a blocking condition-case set up by bytecomp--displaying-warnings when byte-compile-debug is nil. This mechanism is currently only used in Fload. > How is this related to `Fprefix_load_file_names`? Not closely. I think I should have propsed two separate patches, rather than the big one I did. Fprefix_load_file_names is what puts the "While loading foo.el... " in front of an error message. > Stefan -- Alan Mackenzie (Nuremberg, Germany).