Subject: Re: Bug#66912: With `require', the byte compiler reports the wrong file for errors.

From: Alan Mackenzie <[email-masked]>
Date: Tue, 5 Nov 2024 20:33:23 +0000

Hello, Stefan.

Here are some of my thoughts on your new idea.  They probably seem a bit
incoherent, for which I apologise.  I'm trying to think up all the
problems we might have with it first, before trying to implement it.
That will hopefully reduce frustration and hassle.

On Tue, Nov 05, 2024 at 14:00:43 -0500, Stefan Monnier wrote:

> >> >  static Lisp_Object Vloads_in_progress;
> >> > +/* The same as the above, except it survives the unbinding done in the
> >> > +   event of an error, and can thus be used in error handling.  */
> >> > +Lisp_Object Vloads_still_in_progress;

> >> Please clarify how "it survives the unbinding".

> > It is a global variable which never gets bound, hence when an error is
> > signalled and the binding stack unwound, it keeps its value.  But you
> > want me to write this into the comment, not just explain it here.  ;-)

> > I've become a little uncertain about this mechanism.  Should an error
> > occur during loading, and the code somehow avoid calling
> > prefix-load-file-names, perhaps by some obscure setting of `debugger',
> > Vloads_still_in_progress would stay non-nil, and pollute the next error
> > message to be output.  I think the default global value of
> > Vloads_still_in_progress should be Qnil, and I should bind it to itself
> > each iteration of the command loop, probably in command_loop_1.  That
> > would protect it from wierd uses of recursive_edit, and avoid the need
> > to reset Vloads_still_in_progress in prefix-load-file-names.

> > What do you (or Eli) think?

> BTW, stepping back a little I wonder if we shouldn't do it a bit
> differently:

> In `signal_or_quit`, stash the current value of `Vloads_in_progress` into
> the global variable `Vloads_in_progress_of_last_error`.

OK.  This new variable would then have a guaranteed accurate copy of
Vl_i_p.  Should signal_or_quit end up re-invoking itself (as happens, for
example, when there's a throw to an un-caught symbol, when signal_or_quit
throws Qt to Qtop_level), the value of Vl_i_p won't have changed, so
setting it twice won't matter.  At least, I can't at the moment see how
it would matter.

> So the doc doesn't need to explain how
> `Vloads_in_progress_of_last_error` "survives unbinding", it can just
> say it's the info that was current when the last error was signaled.

That would be a good thing, yes.

There needs to be some mechanism for resetting this variable to Qnil,
should the error handler fail to access it.  Possibly by binding it
somewhere where it's binding will be undone before the next command.  Or
maybe not, if an error handler is always preceded by setting
Vl_i_p_of_last_error for that same error.

Also, we need to be careful about condition-cases in debuggers, where an
error, even if handled, might overwrite Vloads_in_progress_of_last_error.
debug.el and edebug.el both contain condition-cases.  We might not like a
necessity to access Vl_i_p_of_last_error before evaluating any
condition-cases.  That would appear to be inviting trouble.

As a wild idea, we could bind some flag to Qt in Fload, and only set
Vloads_in_progress_of_last_error if the flag is still set.  We would
clear the flag at the same time as setting that variable, thus protecting
it against the next condition-case or whatever.  Possibly we could use
Vl_i_p_of_last_error itself, by setting it to t near the start of Fload.

However, signal_or_quit is supposed to be a general low-level function,
and it doesn't seem ideal to bloat it out with special purpose tests.

Another possible problem with this wild idea is that debuggers, or parts
of them, might need to be autoloaded.  This shouldn't be a problem with
edebug.el, where the file would be loaded to be able to instrument a
form, but I don't think anything's loading debug.el before it gets used.

> It may still hold "the wrong info" if by bad luck some other error
> occurred between the error in which you're interested and the moment you
> can read `Vload_in_progress_of_last_error`, a bit like when
> another regexp-match occurs before you use "your match"'s `match-data`,
> but at least semantically, I think it is simpler to explain and
> understand than your current code.

I think that could only happen if there were a bug in a debugger.

I think your idea might be better than my current patch, but I doubt it's
going to be much simpler.

> We could arguably try and generalize this to hold more data than just
> the loads in progress, e.g. merging it with the current
> `Vsignaling_function`, so call it `dynamic-context-of-last-error`
> or something.

Let's get it working first.  ;-)

> > I think I would agree, but this would be difficult for .el[cn] files.
> > How about giving the line number just for .el files, something like:

> That's what I meant, yes.

OK, I'll think about that, but after we've got the basics (see above)
sorted out for this bug.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).