bug#54079: 29.0.50; Method dispatching eratically fails

[Alan Mackenzie]

On Wed, Mar 16, 2022 at 02:44:07 +0100, Michael Heerdegen wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > OK.  So the longer I hear nothing from you, the better.  ;-)  Thanks!

> Hope it was long enough :-)

Indeed it was!  Thanks!

As you'll have gathered, I've been debating the final form of the patch
with Stefan M. for the last week.  The patch I'll actually be committing
will be slightly different from the one from last week, but not in any
way which should affect the success of the problem fix.

> I now tried to debug the other thing that is still happening for me -
> failing compilation with async-bytecomp.el when updating packages with
> M-x list-packages (I CC the maintainers).

> In my currently running session I get

> #+begin_src emacs-lisp
> (async-inject-variables "\\`\\(?:load-path\\'\\|byte-\\)")
>   ==>
>   (setq byte-set-marker 147 byte-optimize--dynamic-vars
>         '(#<symbol magit-log-margin at 854429>
>           #<symbol magit-status-mode-map at 854375> ...)
>         ...)
> #+end_src

> These symbols with position in that sexp seem to be the, or one, cause
> of the trouble.  The symbols directly come from a `mapatoms' call, and
> AFAIK this sexp is then `print'ed and sent to another emacs process,
> where it causes a `read' error.

> What has to be done to fix this one?

I don't know, as yet.  Almost certainly, the symbols with position are
somehow escaping from the compilation context.  It looks like something
in magit.  Possibly, I'll need to ask the magit maintainer to call
byte-run-strip-symbol-positions (which _surely_ ought to be renamed to
strip_symbol_positions) where these SWPs escape.  (Possibly in a macro).

In the meantime, could you possibly raise a fresh bug report for this
one, please, and give a complete recipe for reproducing the bug.
Thanks!

> TIA,

> Michael.