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#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.) Date: Tue, 26 Mar 2024 16:30:06 -0400 Message-ID: References: Reply-To: Stefan Monnier 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="23436"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 67455@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 26 21:31:25 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 1rpDS9-0005tR-Hl for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Mar 2024 21:31:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpDRr-0008Ar-SD; Tue, 26 Mar 2024 16:31:07 -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 1rpDRq-00089w-1M for bug-gnu-emacs@gnu.org; Tue, 26 Mar 2024 16:31:06 -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 1rpDRo-0003RN-KS for bug-gnu-emacs@gnu.org; Tue, 26 Mar 2024 16:31:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rpDRo-0005p5-9e for bug-gnu-emacs@gnu.org; Tue, 26 Mar 2024 16:31:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Mar 2024 20:31:04 +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.171148501722252 (code B ref 67455); Tue, 26 Mar 2024 20:31:04 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 26 Mar 2024 20:30:17 +0000 Original-Received: from localhost ([127.0.0.1]:35161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpDR2-0005mp-LJ for submit@debbugs.gnu.org; Tue, 26 Mar 2024 16:30:17 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:6410) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpDR0-0005ma-SG for 67455@debbugs.gnu.org; Tue, 26 Mar 2024 16:30:16 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2184D10004C; Tue, 26 Mar 2024 16:30:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1711485007; bh=K1ihFcANv1mBIel9GM7rNXXNyFrL/wuW7SEKc4RekIU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XB+xLfjcp173bteBSip9SVeFY+Mb9Iva6kH+PvPsMhSnCC8yJU1nOU6eD862h9i7R zLJ89s4OiLIegxfsC9PYr9kbUn/RaAq1dNqSbPpGoB4x7gGQcWaxR8QFVerzE2RAMi kmA6Epm7NxfwJeLjLYcxReit5WKNNlDx9g+m1m8IsLxv3uffdACsEgDw2xcXndflok KO+E13retXgvoIznt5eLUlc2SA86bmDZttUOOVgoQavqnomvnBzvESzfUth3s0Hjfl +hmyK6phWswUgbDjBjI9TdAa0IXKUR/rzvdUOKy0tx1I1bsuZvQy+Tkm6/UKhj9vKA gOpm+dNWHP2SA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 900AF100046; Tue, 26 Mar 2024 16:30:07 -0400 (EDT) Original-Received: from pastel (unknown [45.72.199.112]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 65F23120131; Tue, 26 Mar 2024 16:30:07 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Tue, 26 Mar 2024 09:48:49 +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:282113 Archived-At: > We now have two distinct uses of SWPs: providing warning source locations > to the compiler (where we want to keep the position as long as possible) > and providing position information for the doc string (where we want to > strip the position from the symbol ASAP, to avoid trying to use the SWP > when we need a plain symbol). If both of these occur together, we want > to keep the SWP. I think I'm beginning to understand. So in the "load from source case", some of your symbols are SWPs and you want to turn them into bare symbols "on the fly" during macro-expansion rather than via a separate "strip" phase, so you want the macro expansion to know whether it's done for "load from source" or for some other purpose and you use `byte-compile-in-progress` as a proxy for that information. Is that it? If so, (and if the stripping happens within macros), then indeed passing it as a separate argument through all the recursive calls to `macroexp--expand-all` would be cumbersome. But I suggest you use another name for that(e.g. `macroexp-strip-position`) so the intention is made more clear. Better yet: to avoid the problem of dynamic scope extending "too far" (i.e. accidentally applying to nested loads/evals/compile/...), you could put the relevant info into `macroexpand-all-environment`. [ That var is also dynamically bound, but we're already careful to rebind it when needed so it doesn't apply to nested uses of macroexpansion. ] >> > By "currently", I mean that a defining form such as defun or defvar has >> > commenced, but not yet terminated; its functions currently occupy stack >> > frames. >> So you mean we're inside `Fdefalias` or `Fdefvar_1`? > Yes, or inside a macro (defun, defmacro, ...) which expands to a > defalias. These are *very* different times: `Fdefalias` and `Fdefvar_1` are executed long after macroexpansion. And they're small C functions which run almost no external code at all, so they "occupy stack frames" only for a very short time. My crystal ball suggests that "currently" may be the wrong way to think about it: maybe instead of thinking of "when" (as in "during the definition of function FOO") what you're looking for might be "where" (as in "within the body of FOO"). [ That's the same difference as the difference between dynamic and static scoping. ] If my crystal ball is right, then the better place to put that info is probably `macroexpand-all-environment`. > Ideally, I would like to have bound defining-symbol inside defun. (defmacro my-defun (name args &rest body) `(cl-macrolet ((defining-symbol () '',name)) (defun ,name ,args ,@body))) (my-defun my-foo (x) (list x (defining-symbol))) (symbol-function 'my-foo) =3D=3D> #f(lambda (x) [t] (list x 'my-foo)) `cl-macrolet` uses `macroexpand-all-environment` for that. > Fload uses read-positioning-DEFINED-symbols, as contrasted with the > compiler, which uses read-positioning-symbols. r-p-d-s positions only > lambdas and NAMEs. r-p-s positions all symbols except nil. I think I'm beginning to understand (I guess I was struggling with your use of "position" as a verb for some reason which made me think that symbols were being moved rather than gaining position information). So, IIUC you use `read-positioning-DEFINED-symbols` instead of `read-positioning-symbols` because it's cheaper? Do you have rough numbers comparing the cost of `read`, `read-positioning-symbols`, and `read-positioning-DEFINED-symbols`? Also, IIUC you don't have a separate phase to strip the SWPs when loading from source, but instead you strip them as you "consume" their info during macroexpansion. If so, how/when/where do you strip the false positives that may occur inside quoted data or in code like: (defmacro foo (lambda bar) ...) (defmacro foo (defun bar) ...) (let* ((lambda foo) (defun bar)) ...) > Ah, right. I hadn't considered this before. The changes are by their > very nature essentially complicated and difficult to understand. [ Hmm... maybe not the best salespitch. ] >> I think you can simply wait to add the entry to >> `macro-declarations-alist` until a later time, so the `defining-symbol` >> thingies will be ignored during the early bootstrap and once we have >> more infrastructure in place we can then register the handler on >> `macro-declarations-alist`. > > This will not be simpler. It would involve re-evaluating defun, then > compensating for all the functions up to now whose NAMEs had been read > without positions. Not at all. Those will remain without position, but only in `src/bootstrap-emacs`. In the real `src/emacs` they will get the position because they'll come from the `.el[cn]` file and by the time we get compile those files `macro-declarations-alist` will be fully populated. > There is unavoidable conplexity, here. I'm definitely not convinced. I suspect you've been asking yourself "can it be made simpler" and you may indeed then convince yourself that the answer is no, because of assumptions you don't reconsider. Try instead to think about "what would it take to remove that complexity?". > I see things somewhat differently. We shouldn't increase the debugging > burden even on "expert users". Yet it's imposing more complexity (and hence more debugging burden) on those same expert users. =F0=9F=99=81 Stefan