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

Previous Next

Full log

View this message in rfc822 format

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: bug#66912: With `require', the byte compiler reports the wrong file for errors.
Date: Sat, 09 Nov 2024 11:45:36 -0500

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

Then I don't know what "the message" you're referring to.
(or are you referring to some other point you made elsewhere?)

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

[ I'd make it user-visible, as well Vload_in_progress, but that's not
  actually relevant.  ]

Even if it's not directly exposed to the user the info *is* available,
so we can offer ways to make use of it.

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

If `load-in-progress-at-error` hold (C B A), I'd make the error message
emit either nothing, or just C, or B and C, or A and B and C depending
on where in the call stack we're calling from (using the `while` loop
that compares to `load-in-progress`).

From within the debugger, presumably `load-in-progress` would still be
(C B A), so error messages would usually display no "while loading" at
all, unless the errors themselves occur within a load of some file D,
of course.

Note that this is not just the behavior we happen to get with the hacks
I came upon along the way.  It's the behavior I'm aiming for (e.g. it's
also the behavior that we'd get with the `handler-bind` approach
I advocated earlier).

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

Sorry, I meant

    (equal (prefix-load-file-names
            (error-message-string ERROR-OBJECT))
           (prefix-load-file-names
            (error-message-string ERROR-OBJECT)))

[ I assumed you had added a call to `prefix-load-file-names` in
  `error-message-string`.  Not sure why you didn't, but I haven't
  thought very much about which option is best in this regard.  ]

> Can we get this bug closed soon, please?

As I said, you don't need to convince me.


        Stefan

Previous Next

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