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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>>     (while (not (equal Vloads_in_progress_of_last_error Vloads_in_progress))
>>       (setq msg (concat msg " while loading "
>>                         (pop Vloads_in_progress_of_last_error))))
>
> This doesn't make sense in the current implementation (sorry for not
> sending you a patch), because Vloads_in_progress_at_error is copied from
> Vloads_in_progress in signal_or_quit.

I don't understand why you say it doesn't make sense:

An error in signaled from with a => B, so in `signal_or_quit` you copy
`Vloads_in_progress` which contains `("B" "A")` to
`Vloads_in_progress_at_error` and then you throw the error at the
condition-case which was installed (say) from within the file A so
when you reach the handler, `Vloads_in_progress` will have been reset to
`("A")` so the above loop will correctly say that the error occurred
from within B.

>> > I've tried it, and the above problem seems definitely to make it less
>> > simple than the approach I originally took (which currently works).
>
>> AFAIK, your previous approach suffered from the exact same problem, tho
>> maybe in fewer cases.
>
> No, it doesn't.  There, Vloads_still_in_progress is kept in synch with
> Vloads_in_progress when Fload operations start and end.  When the
> debugger or error handler outputs a message using Vl_still_i_p, it
> resets that variable to nil, preventing it getting output again.

You may be right that the "fewer" case are so few so that there really
aren't any.  I'm not convinced there cannot be a code path that happens
not to pass via those settings to nil, but maybe you're right.
Still, my A => B => compile => C => D examples still stands, which is
still at heart the same problem IMO, and could be worked around with my
`while` loop above.

> At the moment, I think my currently working solution is the best way
> to go.

[ As you can guess, I disagree, mostly because I think the problems of
  my suggested approach are "familiar", since the behavior can be
  compared to things like the match-data, so we know how to live with
  its shortcomings, whereas I can't think of something else we already
  have which follows an approach like yours, so we're in new territory
  and it's harder to see what the problems could be and what workarounds
  to use.  ]

Then you'd be better get cracking at the documentation of "survives
unbinding" 🙂


        Stefan