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#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.) Date: Mon, 8 Apr 2024 08:32:57 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4260"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, Eli Zaretskii , 67455@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 08 10:34:14 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 1rtkSD-0000un-OG for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Apr 2024 10:34:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rtkRy-0005M7-EK; Mon, 08 Apr 2024 04:33:58 -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 1rtkRw-0005Lv-W2 for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 04:33:57 -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 1rtkRv-0002GI-7I for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 04:33:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rtkS2-0003qz-6F for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 04:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Apr 2024 08:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67455 X-GNU-PR-Package: emacs Original-Received: via spool by 67455-submit@debbugs.gnu.org id=B67455.171256519714552 (code B ref 67455); Mon, 08 Apr 2024 08:34:02 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 8 Apr 2024 08:33:17 +0000 Original-Received: from localhost ([127.0.0.1]:45246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtkRI-0003me-D3 for submit@debbugs.gnu.org; Mon, 08 Apr 2024 04:33:16 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:26581) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtkRF-0003mP-So for 67455@debbugs.gnu.org; Mon, 08 Apr 2024 04:33:14 -0400 Original-Received: (qmail 24139 invoked by uid 3782); 8 Apr 2024 10:33:00 +0200 Original-Received: from muc.de (p4fe15203.dip0.t-ipconnect.de [79.225.82.3]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 08 Apr 2024 10:32:59 +0200 Original-Received: (qmail 6741 invoked by uid 1000); 8 Apr 2024 08:32:57 -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:282918 Archived-At: Hello, Stefan. On Sun, Apr 07, 2024 at 23:16:13 -0400, Stefan Monnier wrote: > > Pretending the problem doesn't exist won't solve it. In the ;POS... > > structures for a lambda, there are two pointers - one to the definition > > of the lambda, the other to the point of use. > Fancy. Could you give me an example where I see this in play? > [ To help me understand also what you mean by "definition of the > lambda" and "point of use"? ] > I looked around but all I could see where position info like > [foo foo.el 41 nil] > which point to "the definition" of the function. Apologies. I was thinking of my latest not yet committed version, where I've added a fifth element into the position information, the buffer containing the lambda. This should enable buttons to be set on the interactive backtrace, pointing back at the two source code positions. > >> BTW, AFAIK the above is conceptually what the byte-compiler does (exce= pt > >> it performs a few more transformations between `macroexp--expand-all` > >> and `strip-all-symbol-positions`). > > It is a bad idea to conflate these two radically different uses of SWPs. > In what way are they radically different uses of SWPs? You're confused in precisely the way I feared. "conceptually what the byte-compiler does" is what it does to strip the SWPs used as WARNING POSITIONS. When the SWPs are used for function position structures (whether in interpreted or compiled code) the handling is radically different - the P in the SWP is stripped as soon as possible after its use. In the warning pos use, the positions are preserved for as long as possible. > >> Is it the case that `cl-defmethod` generates a function whose source > >> position (partly) points to `generic.el:403` if `cl-generic.el` was > >> interpreted but not if it compiled? > > No, the intention is that the source positions are independent of wheth= er > > the code is compiled. > Good. So why do the interpreted and compiled cases need to be > "radically different uses of SWPs"? They're not. It is the use for warning positions that differs from the use for putting pos info into the doc string. > >> > (defmacro foo (lambda bar) > >> > `(cons ,lambda ,bar)) > >> > expands to > >> > (macro closure (t) (lambda bar) ";POS^^^A^A^A [foo *scratch* 158 nil] > >> > " (list 'cons lambda bar)) > >> IIUC your reader will make the `lambda` formal argument into an SWP. > >> Where is that SWP stripped? > > In macroexp--expand-all in the "guard arm" near the end. > How? `macroexp--expand-all` will not be passed this `lambda` because > it's not an *expression*. Well, when I commented out that pcase arm, the lambda no longer got stripped. I'm not sure what you mean by expression. > `eval-buffer` of a buffer containing the above defmacro does: > 1 -> (macroexp--expand-all (defalias 'foo (cons 'macro #'{foo} (lambda (#= bar) ";POS=01=01 [foo foo.el 41 nil]\n" `(cons ,lambd= a ,bar))))) > | 2 -> (macroexp--expand-all 'foo) > | 2 <- macroexp--expand-all: 'foo > | 2 -> (macroexp--expand-all (cons 'macro #'{foo} (lambda (# bar) ";POS=01=01 [foo foo.el 41 nil]\n" `(cons ,lambda ,bar)))) > | | 3 -> (macroexp--expand-all 'macro) > | | 3 <- macroexp--expand-all: 'macro > | | 3 -> (macroexp--expand-all #'{foo} (lambda (# ba= r) ";POS=01=01 [foo foo.el 41 nil]\n" `(cons ,lambda ,bar))) > | | | 4 -> (macroexp--expand-all ";POS=01=01 [foo foo.el 41 nil]\n") > | | | 4 <- macroexp--expand-all: ";POS=01=01 [foo foo.el 41 nil]\n" > | | | 4 -> (macroexp--expand-all `(cons ,lambda ,bar)) > | | | | 5 -> (macroexp--expand-all 'cons) > | | | | 5 <- macroexp--expand-all: 'cons > | | | | 5 -> (macroexp--expand-all lambda) > | | | | 5 <- macroexp--expand-all: lambda > | | | | 5 -> (macroexp--expand-all bar) > | | | | 5 <- macroexp--expand-all: bar > | | | 4 <- macroexp--expand-all: (list 'cons lambda bar) > | | 3 <- macroexp--expand-all: #'{foo} (lambda (# ba= r) ";POS=01=01 [foo foo.el 41 nil]\n" (list 'cons lambda bar)) > | 2 <- macroexp--expand-all: (cons 'macro #'{foo} (lambda (# bar) ";POS=01=01 [foo foo.el 41 nil]\n" (list 'cons lambda bar))) > 1 <- macroexp--expand-all: (defalias 'foo (cons 'macro #'{foo} (lambda (#= bar) ";POS=01=01 [foo foo.el 41 nil]\n" (list 'cons l= ambda bar)))) > So we see that indeed it returns code where the formal argument `lambda` > is (incorrectly) a SYMPOS. Yet somehow the sympos is stripped after > macroexpansion somewhere since `(symbol-function 'foo)` shows the > resulting function doesn't have any symposes in it. OK, this needs clearing up. > >> > so it is clear this case is getting handled OK. I'm afraid I can't > >> > point out the exact place in the code at the moment where this is > >> > getting done. > >> I think it would be good to know, so as to be able to decide whether > >> it'll indeed always work right, or we just got lucky this time. > > See above. > Yes, please, see above =F0=9F=99=82 > >> Could you explain what you think makes it intrinsically complex? > > The mass of detail that needs dealing with that Emacs has collected over > > the decades. As a counter question, why do you think the exercise ought > > to be simple (assuming you do think this)? > Because you solved the hard part when you added the symposes for the comp= iler. OK, but that's not the way things turned out. > Stefan --=20 Alan Mackenzie (Nuremberg, Germany).