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

Previous Next

Full log

Message #152 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, 12 Nov 2024 10:38:47 -0500

> OK, so you were using "the point in the chain where we catch the
> error", which is of no interest to the user, as a proxy for how and
> where an error message gets displayed.

I conflate the two, yes.

> I thought we were agreed that the "A => B => compile => C => D" was
> vanishingly rare and probably doesn't occur at all in the Emacs sources.

I like to think of such corner cases because it gives me more clarity
about the general case.  If I focus only on the scenario at hand it's
all too easy to design something that doesn't work well in the
general case.

> In that case, why are you giving it priority over the other concerns
> (such as consistency of messages displayed to the user) that I have
> raised?

Because I don't see the benefit of using "consistent" messages when
the circumstances are very different.

> Would you please clarify whether you are opposed to outputting the
> information (about the stack of files being loaded) in the debugger
> case, or are merely indifferent about it.

I'm indifferent about it.
But I do care about the debugger showing me the error *object* rather
than merely the error *message*.

> It is true that Emacs error messages are typically poor in the extreme,
> in that they fail to identify the pertinent command, buffer, hook, or
> variable.  I have been trying to improve this for several years, with
> mixed success.  The thing about loading is that it is frequently
> recursive, typically by the function `require'.  Being told which file
> the failing Lisp came from is as good as saying which buffer, and likely
> better in batch mode.

That's why I'm thinking of generalizing the `load-in-progress-at-error`
into a `dynamic-context-at-error` where we could stash arbitrarily more
information.  Ideally, error objects would come with a full backtrace,
from which we could extract the stack of pending loads, the name of the
current command, or process filter, or hooks, ...
[ In SML/NJ, exception objects keep a reference to the "stack" for that
  purpose, but of course, that's easy for them because they heap
  allocate their "stack", so it's a simple matter of keeping
  a reference, whereas we'd have to copy our "stack", which could
  slow down `signal` significantly.  ]

>> > I think it would be consistent to display "While loading..." the same
>> > in both cases.
>
>> To be honest, I don't see much value in displaying "while loading" in
>> the echo area in general.
>
> To be frank, displaying nothing but
>
>     Wrong type argument: integer-or-marker-p, nil
>
> to the user is insulting.

Agreed.  At the same time, it corresponds to Python dumping a backtrace
onto the unsuspecting user, or C crashing down with a core dump, so
I think we're in good company.

IOW when the end user sees such an error message, it means we have a bug
in the ELisp code somewhere.  The bug is either in that we should not
trigger this error, or that we should catch it and turn it into an error
that's meaningful in the context of the command where it's executed.

Note that in presence of such a bug, adding "while loading A" won't
really help.
The only two behaviors that would help would be either to drop
into the debugger (so as to help diagnose/find/fix the bug), or to emit
a message explaining to the user that they found a bug (and maybe try
and help them submit a bug report).

Dropping into the debugger is what we get with `debug-on-error`, but
I don't think we can enable it by default, because it's a bit too
delicate to use for some users.  Maybe we should improve that.

> Informing the user which file the error occurred in, though far from
> ideal, is significantly better than not doing so.

IME, the above kind of error usually happens outside of loading files,
so bug#66912 will almost never make a difference for that kind of error.

>> I'm not opposed to it, but the only case where I know it could be
>> helpful is during compilation (which I'm mostly interested to see it
>> in the compilation buffer).
> In this case, the error message is indeed displayed in *Compile-Log*.

🙂


        Stefan

Previous Next

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