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

[Mattias Engdegård]

4 dec. 2023 kl. 19.19 skrev Alan Mackenzie <acm@muc.de>:

> You've undone the bug fix, and the bug is there again.

Oops. An honest mistake, very sorry about that.
On the other hand, these blunders often turn out to be beneficial in the end 
because they force us to take a better look at the problem.

I ended up maintaining `byte-compile-form-stack` in `cconv-convert` which isn't 
free but a lot better than doing it in the optimiser. We emit a fair amount of 
warnings in cconv so this should be useful for other reasons as well.

The warning was also reverted from delayed to immediate, which makes sense in 
this case (since it's essentially a syntax error) and in fact it wouldn't work 
otherwise because delayed warnings implicitly use the byte-compile-form-stack 
we have when traversing the post-optimisation tree in codegen.

I'm inclined to do something about this last problem for good measure (see 
attached patch). Most of the time the byte-compile-form-stack doesn't matter 
much because the warning argument contains a symbol with position, but when it 
does, the stack state in codegen when the warning is emitted is likely to be 
less useful than when the warning was registered in the front-end. Haven't made 
up my mind about this yet.

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

Yes, so I noticed. This is rubbish of course; we should do something about it. 
We have some options.
Meanwhile I made a macro to encapsulate the ugly push-pop logic in one place.

0001-Capture-byte-compile-form-stack-in-delayed-warnings-.patch
Description: Binary data