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

From: Mattias Engdegård <[email-masked]>
Date: Thu, 21 Dec 2023 13:22:17 +0100

4 dec. 2023 kl. 19.19 skrev Alan Mackenzie <[email-masked]>:

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