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

[Stefan Monnier]

>> But there are also cases in between where it's less clear, mostly with
>> errors during macro-expansion where the internal/external distinction is
>> not always that clear since some macros come from outside but others
>> come from the very file we're compiling, and where we can't easily tell
>> if an error is due to a bug in the macro definition or a bug in the use
>> of the macro.
>
> Question: will the user be able to identify the macro and its source
> file if we just print the bare error message as enforced by
> displaying-byte-compile-warnings?

I think we print a "bare" error message (together with the location of
the macro call).  Often it's good enough (e.g. when the error is really
in the macro call itself).  Sometimes it's very perplexing :-(

> It the answer is no or not really, we should give her the backtrace to
> get started on.

Says the one who claimed earlier that backtraces are stressful :-)

Dumping the backtrace is a kind of cop-out.

Don't get me wrong, I love backtraces, but I don't think we should
blissfully throw backtraces at unsuspecting users (unlike Python, say).
IOW, we should first work harder to provide better error messages.

>> For the first, the current "solution" is to set `byte-compile-debug`.
>> It's not ideal, and we should improve it, but at least we do have
>> a solution for it.
>
> I suspect byte-compile-debug isn't widely known.  Its name is also a bit
> discordant - it's not necessarily about debugging byte-compile, it's
> just to get sensible error messages when something goes wrong,
> especially when that something is not part of the byte compiler.

Agreed.

>> For the second we currently don't show a good enough info and in my
>> previous response I focused on that part.
> Indeed, for the error message which provoked this bug report, the
> current information is poor indeed.  Considering that require's can be
> nested, we only tell the user the identity of the outermost one.

We don't even give that info.  We just give the line number of the
`require`.  It's almost as good as the outermost file name, but not quite.

> It's "neat and tidy", but at the cost of discarding all useful
> information.  There are other common situations in Emacs where
> the debugger is entered, or a backtrace output without debug-on-error
> having to be set.

Hmm... I can't think of such a situation.  When/where do we show
a backtrace without the user's explicit request?

>> So maybe those `condition-case` should be turned into
>> `condition-case-unless-debug`?
> I think this would be a very useful first step.  I think it likely a
> user will set debug-on-error on encountering any unhelpful error
> message.

AFAICT this would basically be equivalent to aliasing
`byte-compile-debug` to `debug-on-error`.

It may turn out to be annoying occasionally, but I think it's worth
a try (I've never found it useful to have `byte-compile-debug` set to
t without also setting `debug-on-error` to t).


        Stefan