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

[Stefan Monnier]

>> I don't understand the above code: `handler-bind` is not supposed to
>> call setjmp/longjmp: when the handler of a `handler-bind` gets called,
>> the stack is not unwound.
>
> I started off by just making the HANDLER_BIND case use the same code as
> CONDITION_CASE, and got segfaults.  I've tried to find the places where
> a longjmp gets called for condition-case, but my brain's tired after a
> weekend of heavy coding.

The longjmp is in `unwind_to_catch`, called from `signal_or_quit`, but
we only get there for CONDITION_CASE, not for HANDLER_BIND.

> Given HANDLER_BIND doesn't need the setjmp/longjmp mechanism, it would
> seem there's no sense in combining the HANDLER_BIND and CONDITION_CASE
> cases in internal_cc_hb and friends.  I should just restore the
> condition-case functions to what they were, and add separate new ones
> for handler-bind.

OK.

> I think I see now you're right.  push_handler doesn't push an entry onto
> the binding stack.  I'll amend these comments as soon as I understand
> the code.  I think these lines definitely need comments.

Maybe pointing the reader to the SKIP_CONDITIONS comment in `lisp.h`?

>> Also there's no reason to presume the HANDLER_BIND handler is at the
>> top, so if we wanted to remove it, we'd have to work harder.
> This code is difficult to understand.  What is the purpose of the
> binding block around the call of the handler function?  I think a
> comment here would help.

The `unbind_to` is there because `max_ensure_room` may
`specbind` something.  In 99% of the cases it does nothing.

>> How is this related to `Fprefix_load_file_names`?
> Not closely.  I think I should have propsed two separate patches, rather
> than the big one I did.  Fprefix_load_file_names is what puts the "While
> loading foo.el... " in front of an error message.

Splitting it into two would be good yes.
AFAICT, the `Fprefix_load_file_names` is the part that aims to address
bug#66912.  IMO the other belongs in another bug-report/feature-request?


        Stefan