--- Begin Message ---
|
Subject: |
30.0.50; New trouble with symbols with positions |
|
Date: |
Sat, 04 Mar 2023 17:18:43 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hello,
since a couple of days, maybe around a week, master builds bug me with
symbols with positions again.
Here is a recipe for emacs -Q (dunno, there may be much simpler and
shorter recipes, didn't try):
Save this into a file:
swp-test.el
Description: application/emacs-lisp
Visit and M-x eval-buffer. M-: (test) yields xxx as expected.
But now compile (C-c C-b) and M-: (test) unexpectedly (I guess?)
yields (#<symbol xxx at 63>), a symbol with position.
TIA,
Michael.
In GNU Emacs 30.0.50 (build 11, x86_64-pc-linux-gnu, cairo version
1.16.0) of 2023-03-04 built on drachen
Repository revision: 1b726f26986fa54751f613d1e332fd20c705e17f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
Configured using:
'configure --with-x-toolkit=no'
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY OLDXMENU PDUMPER PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF WEBP X11 XDBE XIM XINPUT2 XPM
ZLIB
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#61962: 30.0.50; New trouble with symbols with positions |
|
Date: |
Tue, 7 Mar 2023 10:24:41 +0000 |
Hello, Michael.
On Tue, Mar 07, 2023 at 01:29:21 +0100, Michael Heerdegen wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > I think I now understand what's going on. It's all to do with stripping
> > symbol positions in eval-and-compile forms. Before the patch of ~two
> > weeks ago, the positions were stripped in e-and-c. After the patch,
> > they weren't stripped.
> > I think the correct thing to do is to strip the symbol positions in the
> > `eval' part of eval-and-compile, but leave them alone in the `compile'
> > part. This is actually quite tricky, since
> > byte-run-strip-symbol-positions works destructively. So I need to copy
> > the code first, and there is no suitable function to do this. copy-tree
> > is close, but can't handle circular lists. So I will have to write a
> > safe version of copy tree.
> Sounds all plausible. I also don't have a better idea.
I've now written safe-copy-tree, and committed it together with the fix
in bytecomp.el to master. So I'm closing the bug with this post.
> > In the mean time, could you try out the following patch which uses
> > copy-tree as a first approximation. I think it fixes the problem,
> > apart from the above.
> Yes, looks good.
Thanks!
> I wonder now if other cases also suffer from the problem. What happens
> when I call `eval' in a macro expander (i.e. while generating the macro
> expansion, not in the result of an expansion)? And how does
> `cl-eval-when' behave (this is actually a special case of the first
> question) ?
I think these are so far unsolved problems with the
symbols-with-position mechanism - sometimes the s-w-p leaks out of macro
contexts. Are you seeing this problem in real life?
> Thanks so far,
> Michael.
--
Alan Mackenzie (Nuremberg, Germany).
--- End Message ---