From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors. Date: Wed, 30 Oct 2024 18:31:35 -0400 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4745"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 66912@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 30 23:32:39 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 1t6HEz-00012Q-HC for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Oct 2024 23:32:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t6HEg-0001nn-24; Wed, 30 Oct 2024 18:32:18 -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 1t6HEc-0001nR-KB for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 18:32:15 -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 1t6HEQ-00062o-Fi for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 18:32:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=2vm4RXRit7RypohjHZahG9nO4SNDugAUy/us2eUItSs=; b=W0sB24AprgH1KQzjHuXn9HC32lwoC5Zat4tyOR+0ar2HUKUUjHwjMrVbcYOLlPpExn+IAIkVAqkS6lDflVNrisEmCmlhdAAWv3f4cTt8yE9GaZysgyobkk3HkVyh9hTFevheHh7dbk5vtkf2nRX9qN7ztxcMt+mZLI6E5LFm32mFKD3zWGVcsWSBUxlbNsY9JefWu8YMLbX1jcGXsL52o2hP1HQGhjckKLHzcyWc3pOzZvQJIrBy2HNaTeRTykbgfImfcYrAOkruDgV/GI7Ba92P3KBqbNx8LQLGQcfdHF867KOpyq34M1Wqexi4mUab+NwBM7+z1nJzdiG5oP4ZkA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t6HEQ-0003c8-18 for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 18:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Oct 2024 22:32: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.173032751513882 (code B ref 66912); Wed, 30 Oct 2024 22:32:01 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 30 Oct 2024 22:31:55 +0000 Original-Received: from localhost ([127.0.0.1]:37927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6HEJ-0003bq-2p for submit@debbugs.gnu.org; Wed, 30 Oct 2024 18:31:55 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:35129) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6HEH-0003bh-9U for 66912@debbugs.gnu.org; Wed, 30 Oct 2024 18:31:54 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id ABE13444446; Wed, 30 Oct 2024 18:31:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730327504; bh=SJtYuhkr0os8EW/w6xaA5+24umxcZCJGcP+LJjtdDbs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZYj2FhR1rgUu2KyF8wL/6+kEOwu/VGid6oA02hJBm2zU5jjmKgGMlu5JExdDxQokb tdHkCRiNv4bggNGNwFIaeXpDC8JSYK+hWEhHJxswz9FbMVBhQZxGdQ2qVvyW888bHD pnCU902TIKiz3knhVcbdRXWKvQPEYZZS2b7UfS5T5TydYkMNsp3hvOCoIMsMIzMQb+ tMV+xFUwsaCBIsC9gLeduvR5nYc/Lx4RHDrcW7bPGAVRZXqzOvyeoWHb8e9cf54FxG GXqw1ArncL0olaujL4ivRFCvBzmep0GjfiCymttC3LNY1llUKeCHBCkC+fam6563hz SmsRUPkP5kgAA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 082E8444444; Wed, 30 Oct 2024 18:31:44 -0400 (EDT) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EBBD2120346; Wed, 30 Oct 2024 18:31:43 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Wed, 30 Oct 2024 21:52:13 +0000") 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:294585 Archived-At: >> 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`. 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`. >> `combine-error-info` is a bit problematic because we don't have clear >> rules about the content of (cdr err), other than the fact that it should >> be a list (tho we don't even enforce that very much). >> Most likely we could append elements to that list, but we'd have to >> worry about interactions with other libraries wanting to do similar >> things. > > Do other libraries actually do such things? Currently, this would be the first, but since I added `handler-bind` I've already felt like doing such things on a few occasions, so it's only a question of time. >> 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. >> Emacs Lisp guarantees that the `err` we get here will be the exact same >> object that any subsequent `condition-case` will get when it finally >> handles the error so that it can use `gethash` to fetch our >> side information. > >> 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. In my suggestion I also accumulate them, but I put them in the side-info hashtable instead of inside the error object. I think it is important to preserve the `eq`ness of the error object (since it embodies the fact that we're still handling the same error), so if we don't use a side table we would probably want to "combine" by mutating the error object. > And I think any call to the debugger on account of debug-on-error should > be in the innermost recursive `require', where the error is actually > signalled, so as to be of maximum use to the person debugging it. 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. More concretely, with your code, I think the debugger will be called with a stack that looks like signal(...) ... signal(...) ... error("the actual error") ... handler-bind(...) ; the inner one require(...) ... handler-bind(...) ; the outer one require(...) whereas with the code I suggest the stack should look like error("the actual error") ... handler-bind(...) ; the inner one require(...) ... handler-bind(...) ; the outer one require(...) 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. Stefan