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

[Mattias Engdegård]

22 dec. 2023 kl. 12.24 skrev Alan Mackenzie <acm@muc.de>:

> What's the process of converting to a closure
> got to do with maintaining the stack of forms for error processing?

Not much, but cconv has evolved to one major part of the compiler front-end 
(the other being macroexp-all) and isn't restricted to just closure conversion. 
In fact, it's now used for dynbound code as well.

In particular it's a natural place for various front-end checks and transforms, 
so don't let the place and name distract you. There are plans to refactor it 
later on for other reasons.

> Whoops!  There was no patch.

Attached it now, sorry.

> You've put the new macro into macroexp.el.  This file is purely about
> macro handling.

Actually macroexp.el does more than that, and in any case the file isn't very 
important; the macro ended up there to be next to byte-compile-form-stack. Nor 
is the name; it can be changed at any time.

However, it probably needs to be in that file for bootstrap reasons.

> And is the "--" in the name
> appropriate, given that the macro is used by several files?  I'm not
> sure about that rule.

The double-dash just means that users shouldn't get any funny ideas. (The 
converse isn't true: a name without double-dash isn't automatically fair game.)

> Also, byte-compile-form-stack gets bound in cconv-closure-convert.  Why?

It's just a backstop. Not strictly needed. It's probably fine to remove it if 
you are worried, but then again there shouldn't be any (non-bug) error 
signalling here. I'll have a look.

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