bug#46834: 28.0.50; byte-compiling the standard counter closure fails

[Pip Cet <pipcet@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

On Sun, Feb 28, 2021 at 6:08 PM Pip Cet <pipcet@gmail.com> wrote:
> (My apologies if this is well-known, documented, or plain stupid on my
> part, but I think it's an interesting gotcha. Feel free to close
> immediately in those cases.)
>
> Steps to reproduce from emacs -Q:
> Evaluate the following in a lexically-bound Emacs Lisp buffer:
>
> (byte-compile (let ((l 0)) (lambda () (cl-incf l))))
>
> Expected result:
>
> A byte code object which will increment its return value by one every
> time it is called.
>
> Actual result:
>
> A byte code object which always returns 1.

So, investigating a little, byte-compile--reify-function does not do,
and as far as I can tell has never done, what it claims to do in its
docstring.

(byte-compile--reify-function (let ((x 0)) (lambda () (cl-incf x))))
=> (lambda nil (let ((x '0)) (setq x (1+ x))))

Obviously, the closure generated on the LHS is not equivalent to that
generated by evaluating the RHS.

Also, while we're there:

(byte-compile--reify-function (let ((x 0)) (let ((x 1)) (lambda ()
x)))) => (lambda nil (let ((x '1) (x '0)) x))

The closure on the LHS returns 1 (correctly); the transformed closure
generated by evaluating the RHS returns 0.

Patch attached. I've looked through the generated bytecode for all of
lisp/ and there appear to be no significant differences.


Pip

[-- Attachment #2: 0001-Compile-closures-that-modify-their-bound-vars-correc.patch --]
[-- Type: application/x-patch, Size: 1448 bytes --]