GNU bug report logs - #66912
With `require', the byte compiler reports the wrong file for errors.

Previous Next

Full log

Message #89 received at 66912 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 66912 <at> debbugs.gnu.org
Subject: Re: Bug#66912: With `require', the byte compiler reports the wrong
 file for errors.
Date: Tue, 05 Nov 2024 14:00:43 -0500

>> > Here's the amended patch.  It's a lot shorter (and easier) than the
>> > previous version.  I would like to commit it as the fix to bug#66912.
>
>> Thanks.  I'm not in love with this approach, among other things because
>> of the problem I described earlier:
>
>>     But I don't think it would be correct in all cases: if file A loads
>>     file B which compiles file C which loads file D which signals an
>>     error we want the compiler error message to say "error in D loaded
>>     from C" and not "error in D loaded from C loaded from B loaded from
>>     A".
>
>> but it's not the end of the world, so I don't object to installing it on
>> `master`.
>
> OK, thanks!
>
>> >  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 `Vload_in_progress` into
the global variable `Vload_in_progress_of_last_error`.

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

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.

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.

> 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.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.