Subject: bug#61962: closed (Re: bug#61962: 30.0.50; New trouble with symbols with positions)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 07 Mar 2023 10:25:02 +0000

Your bug report

#61962: 30.0.50; New trouble with symbols with positions

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
61962: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61962
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#61962: 30.0.50; New trouble with symbols with positions
From: Alan Mackenzie <[email-masked]>
To: Michael Heerdegen <[email-masked]>
Cc: Mattias Engdegård <[email-masked]>, Eli Zaretskii <[email-masked]>, [email-masked]
Date: Tue, 7 Mar 2023 10:24:41 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello, Michael.

On Tue, Mar 07, 2023 at 01:29:21 +0100, Michael Heerdegen wrote:
> Alan Mackenzie <[email-masked]> 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).

Subject: 30.0.50; New trouble with symbols with positions
From: Michael Heerdegen <[email-masked]>
To: [email-masked]
Date: Sat, 04 Mar 2023 17:18:43 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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:

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