bug#67483: Wrong warning position given by the byte compiler for a malformed function

[Alan Mackenzie]

Hello, Mattias.

On Thu, Nov 30, 2023 at 11:37:31 +0100, Mattias Engdegård wrote:
> >     Buffer bad-error-position.el:2:4: Warning: `foo' is a malformed function

> > ..  This position 2:4 is wrong; it is the position of the `let' symbol.
> > The correct position would be 3:6, the position of the `if' symbol.

> (Actually the correct position would be the position of the string
> literal but of course our location tracking system is too simplistic
> for that.)

Indeed.

> Thank you for bringing this to our attention. Now I only saw this from
> the reference in your commit message; would you CC me next time?
> (Stefan, too, unless he objects.)

OK.

> I'm modifying your work a bit because we're trying to remove warnings
> from the optimiser, not entrenching them there. The warning is now in
> cconv but perhaps it should be moved to macroexp-all, it's not very
> important.

Many people consider accurate diagnostics to be very important.

> I hope being able to reshape the front-end a bit later on.

Well, I can hardly say thank you, here.  You've undone the bug fix, and
the bug is there again.  Did you actually test it before commiting your
change?  What should I do, now?  Reopen the bug and ask you actually to
fix it?  Or put the fix back in again myself?

You may not like warning handling code in the optimiser, but unless you
can come up with something better, its presence there is essential to
getting good diagnostics.

> Also, we usually prefer let-binding dynamic variables to push-pop
> pairs.

We do indeed, but here binding the variable simply doesn't work.  Parts
of the compiler, when they encounter errors, signal an error which gets
caught by a condition-case somewhere.  This would unbind
byte-compile-form-stack before the warning handlers could get a chance
to use it.

-- 
Alan Mackenzie (Nuremberg, Germany).