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: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: acm <at> muc.de, 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: Thu, 7 Nov 2024 17:15:49 +0000

Hello, Stefan.

On Thu, Nov 07, 2024 at 11:09:19 -0500, Stefan Monnier wrote:
> > OK, I see what you mean.  But if the error gets handled in a handler-bind
> > handler, or goes through to the debugger without being intercepted by a
> > condition-case, the binding stack will not have been unwound.  In that
> > case the difference between the two lists would be empty.

> Indeed, these are cases where the error hasn't reached its corresponding
> handler yet.  Do you think it's a problem?

Yes.  When the debugger handles the error, the binding stack hasn't been
unwound at all, so Vloads_in_progress and Vloads_in_progress_at_error are
EQ.  So the difference between them would be empty.

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

> > One way to fix this would be to make Vloads_still_in_progress visible to
> > Lisp, and to bind it to nil in the byte compiler.  But that might get a
> > bit complicated.

> And if an error in D gets handled in A, you'd have lost part of the "A
> => B => compile => C => D" context information because the rebinding to
> nil would cause `Vloads_still_in_progress_at_error` to contains only
> the "C => D" part.

Yes.  As I say, it could get complicated.  I don't think such a binding
in the byte compiler is a good idea, but it's a possibility.

> > Something very similar, if not the same, was the original handling of
> > byte-compile-form-stack.

> Something only you worked with, AFAICT.  So it doesn't have the same
> "known issues" advantage for the rest of us.

Oh, come on, Stefan!  It is a very simple mechanism, easily understood,
and it worked without known error for several years, before being
replaced by something more complicated.  How do you think this mechanism
could go wrong if used again for Vloads_still_in_progress?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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