bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed.

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Mon, Jan 10, 2022 at 21:53:36 +0200, Eli Zaretskii wrote:
> > Date: Mon, 10 Jan 2022 19:34:58 +0000
> > Cc: 53164@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > FTR, I didn't see any build problems due to this issue, not even
> > > once.  So I wonder what exactly did you see and in what scenario.
> > > Please elaborate.

> > It took me practically three days solid to diagnose this bug.  The
> > symptom, whilst bootstrapping the scratch/correct-warning-pos, was the
> > following message on stderr:

> >     Error: (invalid-function #<symbol = at 18944>)

> > ..  I quickly tracked down the source of the `=' symbol to lisp/subr.el,
> > in the code for `zerop'.  Further progress was elusive.  In the course
> > of debugging it, I ended up writing my own backtrace routine, free of
> > dependencies, which can work early in the bootstrap, unlike the standard
> > backtrace.

> > The course of events which led to that error message is this:

> > 1. During the bootstrap with native compile, ELC+ELN compiles subr.el.
> >   It does so by getting the LAP code from bytecomp.el via a side
> >   channel.  It completes the compilation.
> > 2. bootstrap-emacs now contains the native-compiled version of subr.el.
> >   Unfortunately, the macro `zerop--anon-cmacro' a complier macro for
> >   `zerop', still contains symbols with position.
> > 3. Having finished the native compilation, ELC+ELN visited subr.el in a
> >   buffer, due to this bug.
> > 4. As part of visiting subr.el, Emacs calls after-find-file, which
> >   invokes find-file-hook.
> > 5. One of the entries in find-file-hook is vc-refresh-state, which gets
> >   called.
> > 6. This causes vc-git.elc to be loaded.  Eventually, vc-git--out-ok gets
> >   called.
> > 7. vc-git--out-ok invokes `zerop', or more precisely the code generated
> >   by the macro `zerop--anon-cmacro'.  This contains #<symbol = at
> >   18944>.
> > 8. eval signals an error, since symbols-with-pos-enabled is nil and it
> >   thus can't handle the symbol with position.  This error gets blocked
> >   from reaching a backtrace function by an inconsiderate condition-case,
> >   which just dumps the message onto stderr.

> > The most obvious cause of the error seems to be at step 3, where
> > bootstrap-emacs spuriously visits the source file.

> After reading this, I still don't understand how come you bump into
> this problem, whereas I don't, and neither does anyone else who builds
> the release branch with native-compilation.  Is this something
> specific to that branch you are working on?

Indeed, yes.  It is the symbols with position which escaped from a
compiler macro.

> If so, why is it urgent to have the fix on the release branch?  The
> branch on which you ware working will land on master.

There was no urgency.  I though the convention was for documentation
fixes and simple safe code fixes to go onto the release branch.  The fix
to this bug, a single line, is well understood and certainly comes into
the category of simple and safe.

> > As I said above, please consider putting the fix to this bug back.  I do
> > not want anybody else to have to go through what I had to to track the
> > bug down.  Leaving stale arguments on the command line, later to be
> > visited, cannot possibly be the Right Thing.  I'm pretty sure it was not
> > done deliberately, it was just a minor oversight which didn't seem to
> > matter.

> There's always one more bug.  When we are so far into the pretest
> process, problems that take unusual steps to reproduce are not
> important enough to delay the release.

OK.  But can I ask you to consider announcing on emacs-devel when the
criteria for making bug fixes on the release branch change?  Apologies if
you have done, and I missed it.

> The judgment call I need to make is how important is it to have this in
> the release branch, and that's only after I understand how to trigger
> the problem in the first place.

It is not particularly important for the release branch.  But it is a
positive step (making the build faster, and removing a potential bug
source).

As for triggering it, I cannot give you a recipe except for committing my
recent changes to scratch/correct-warning-pos, and asking you to repeat
what I did (basically, a make bootstrap).  Somebody else may trigger it
in some other way, and the debugging effort is potentially unbounded.

So, I still think it would be better in the release branch, but can see
that it's not very important.

There're three ways we could go.  Commit it in emacs-28, master, or
scratch/correct-warning-pos.  I'm willing to commit it again in any of
these places.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).