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: Sat, 2 Nov 2024 13:47:12 +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="5133"; 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 Sat Nov 02 14:48:32 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 1t7EUR-0001AE-CU for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 02 Nov 2024 14:48:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t7EU0-0001bZ-L5; Sat, 02 Nov 2024 09:48:04 -0400 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 1t7ETz-0001am-8z for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2024 09:48:03 -0400 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 1t7ETz-0001Wy-0y for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2024 09:48:03 -0400 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=0UgghBxLZ1dNSd7MliA8LGevzxcgRMfF8hGPke6uQN8=; b=oVNX9KpF0vDcoxsdeKRNgyX7c26wLNAXw5AdU20L8aRyw8TsEAv50Jn8n2uoO8/hQhqzi+e2XvLJSUUm2FsMLYWG/lkAuUvVYbDp+4Z1U1rOJyPEICU+6N41/BndkyYerDSDYKKt4V0cXGIaEXEDecSJ7ViJ7dvrycjIWpmA5COjUyc+xmlKJ4g5eW3cXuZvXt9DXyNeX5psxGTobrRogp0gs/j/4fZtq229Ce/cTZWP3M1CNi1JtusfQXP3lR1eVngoDI9STLsi+XvZSiCc7SzasEqtwH1l4DTjgLvYEIIipZAnJgKqLcduvg4w0g3fXnsLOxOwXZRSE2OvepxeiQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t7ETx-0003lT-Sa for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2024 09:48:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Nov 2024 13:48:01 +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.173055524514452 (code B ref 66912); Sat, 02 Nov 2024 13:48:01 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 2 Nov 2024 13:47:25 +0000 Original-Received: from localhost ([127.0.0.1]:53540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7ETM-0003l2-B3 for submit@debbugs.gnu.org; Sat, 02 Nov 2024 09:47:24 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:22358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7ETK-0003ku-5U for 66912@debbugs.gnu.org; Sat, 02 Nov 2024 09:47:23 -0400 Original-Received: (qmail 22255 invoked by uid 3782); 2 Nov 2024 14:47:14 +0100 Original-Received: from muc.de (p4fe154f5.dip0.t-ipconnect.de [79.225.84.245]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 02 Nov 2024 14:47:14 +0100 Original-Received: (qmail 19201 invoked by uid 1000); 2 Nov 2024 13:47:12 -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:294749 Archived-At: Hello, Stefan. On Wed, Oct 30, 2024 at 18:31:35 -0400, Stefan Monnier wrote: > >> I can definitely live with this syntax, but maybe we should use > >> something more like what GCC uses (e.g. for errors in #included files) > >> which puts the "While loading" info on separate lines. > > I thought about that, but seeing as how only one message at a time is > > visible in the message area, we'd probably want to output one message > > with embedded LFs, rather than several consecutive "While loading ..."s. > I don't have an opinion on that. I only care about the case where that > info ends up in a file or buffer, along with other warnings and errors, > such as when I do `make` or `byte-compile-file`. Indeed, it is a relatively small point, which can easily be changed once we have working code. > Ideally I'd like to be able to click on each "While loading" to be > brought to the place of the corresponding `require`. And ideally this > would work with the existing entries of > `compilation-error-regexp-alist`. OK. Again, I think this could easily be added once the basic code is in place. [ .... ] > >> So I was thinking that we should go instead with: > >> (handler-bind ((error (lambda (err) > >> (push file (gethash err our-table-of-error-source))))) > >> readevalloop (Qget_file_char, &input, hist_file_name, > >> 0, Qnil, Qnil, Qnil, Qnil);) > >> Where `our-table-of-error-source` would be a weak eq-hashtable. > > Do we need a hash table when it's only going to have a few elements at > > any time? `require's rarely go more than 5 or 6 deep. Why not just have > > a simple dynamically bound list? Or have I misunderstood what you mean? > A hashtable is not the only solution, indeed. But a weak hashtable > makes it possible to skip the need to use something that's "dynamically > bound", and hence to have to think about where we do the dynamic binding > and what to do if it's nested etc... > IOW, it seems simpler to me. I don't think we need either. In lread.c, there is already a static variable Vloads_in_progress (which despite the name, is not visible in Lisp). This variable is a stack of the file names currently being loaded. We could surely just use this, and avoid code duplication. [ .... ] > >> Note that we don't `signal` the error again, instead we let the error > >> handling code propagate it further, which is what `handler-bind` does > >> when the handler returns normally (which should also eliminate the > >> possible problems of interaction with `debug-on-error`). > > The reason I suggested a signal call was so that the error information in > > the successive ERRs would accumulate, rather than just being the fixed > > ERR from the initial error. I've been working out details in the last two or three days. I actually think the handler should exit with a (throw 'exit t). That's because ... > I think I agree tho "be in the innermost recursive `require'" seems > quite vague. But in any case the handlers of `handler-bind` are run > before we unwind the stack (e.g. if your nesting looks like "require => > require => error" the two handlers of your two `require`s will be run > before we get to the debugger but the debugger will still show the full > stack. Tho with your use of "resignaling" within the handlers, the > stack will tend to be even "more full", with the two handlers nested > and still active), so no matter how we do it, I think we will indeed get > the behavior that I believe you describe. We should respect any user setting of debug-on-error to anything non-nil. If non-nil, we should enter the debugger within the handler-bind's handler, so as to have access to Emacs's state when the error occurred. This mechanism is used in eval-expression. Also, this will prevent the byte compiler having (eq byte-compile-debug nil) subverting the call of the debugger. After all, when loading a file, we're not actually in the byte compiler, so byte-compile-debug shouldn't have an effect. On leaving the debugger after an error, we definitely don't want to enter the debugger again for the next file on the loading stack. Hence we should exit the handler with (throw 'exit t), or something like it. [ .... ] > In any case, it should be easy to try out and change from one to the > other with very local changes (I'd expect that the code of the handlers > will be written in ELisp rather than C, right?). So either way is fine. No, I think the handler code should be in C. The function handler-bind-1 seems very clumsy for use from C code. It requires a function with no parameters, so this would likely involve creating a closure in the C code. This isn't good. We should take inspiration from the functions internal_condition_case and friends in eval.c, and create functions like internal_handler_bind. This would be almost identical to internal_condition_case, but would push a HANDLER_BIND entry onto the handler stack rather than a CONDITION_CASE one. I think this would work well. What do you say to all of this? I'm about to start coding in earnest. > Stefan -- Alan Mackenzie (Nuremberg, Germany).