GNU bug report logs - #51982
Erroneous handling of local variables in byte-compiled nested lambdas

Previous Next

Package: emacs;

Reported by: Paul Pogonyshev <pogonyshev <at> gmail.com>

Date: Fri, 19 Nov 2021 20:32:02 UTC

Severity: normal

Tags: patch

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Erroneous handling of local variables in byte-compiled nested lambdas
Date: Fri, 19 Nov 2021 21:31:13 +0100
[Message part 1 (text/plain, inline)]
Steps to reproduce:

1) save attached file as `wtf.el';
2) execute from command line:

    $ emacs --batch --eval "(byte-compile-file \"wtf.el\")"
    $ emacs --batch -L . --eval "(require 'wtf)" --eval "(print (funcall
(wtf 1)))"

Results, of the first command (byte-compilation):

    In wtf:
    wtf.el:9:17:Warning: reference to free variable ‘it’

of the second:

    Symbol’s value as variable is void: it

Expected results: byte compilation succeeds without warnings, second
command prints "1".

Note that if you change line "(let ((fn #'(lambda () it)))" to e.g. "(let
((fn #'(lambda () nil)))", everything works as expected.  However, 'fn' _is
not even used_ when function `wtf' is called with non-nil argument, which
further conforms that the observed behavior is a bug.  Another indication:
when the function is not byte-compiled (e.g. delete file `wtf.elc' after
the first command), it produces expected results.

Function, of course, doesn't make any sense.  It is a result of removing
contents of real failure until it is as small as possible.

Paul
[Message part 2 (text/html, inline)]
[wtf.el (text/x-emacs-lisp, attachment)]

This bug report was last modified 2 years and 249 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.