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

[Alan Mackenzie]

Hello, Stefan.

On Fri, Nov 08, 2024 at 15:26:51 -0500, Stefan Monnier wrote:
> >> I understand that, but I don't think it explains why you think it's
> >> a problem.  E.g. when you're in the debugger, you can see the stack
> >> trace which tells you we're loading A, so you don't need to be told
> >> "while loading A" in the error message.
> > OK, I see what you mean.  I took it for granted that the message should
> > be the same, regardless of whether it is reported by a debugger or by
> > the error handler.

> AFAIK the debugger does not emit the "error message" at all, it shows
> the error object instead, so it's already different.

That doesn't seem to address the point I made above at all.

> And the full info would readily be available from 
> `Vloads_in_progress_at_error`.

Vloads_in_progress_at_error is not available to the user, being an
internal variable.

The problem with the Vloads_in_progress_at_error approach is that its
information gets prefixed to EVERY error message which occurs while the
debugger's recursive edit is in progress.  This is not a Good Thing.
The methods suggested so far to fix this don't as yet seem satisfactory,
and we don't seem to be progressing on this front.

> >> I'm just describing the way I see it: I personally don't have a good
> >> intuition of how/when it could misbehave nor how to work around such
> >> cases, whereas I very much do for the approach I propose and AFAICT it's
> >> not just because I proposed it but it's because it follows
> >> a known pattern, so I expect the same will hold for other coders.
> > Experience with byte-compile-form-stack suggests it won't misbehave.
> > Its simplicity should make it easy to think through.

> AFAICT

>     (equal (error-message-string ERROR-OBJECT)
>            (error-message-string ERROR-OBJECT))

> will not always return t, which I'd consider as a misbehavior.

No.  The proposed mechanism of Vloads_still_in_progress has no influence
on error-message-string.

> I don't mean that we need to fix it.  Just that that there *will* be
> misbehaviors, because we use a low-tech approach which stashes the info
> in a global variable.

It may be low tech, but it's effective.  Its simplicity makes
misbehaviour unlikely.  We didn't see any (that I know of) with
byte-compile-form-stack.

Can we get this bug closed soon, please?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).