From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#51982: Erroneous handling of local variables in byte-compiled nested lambdas Date: Sat, 20 Nov 2021 17:54:49 +0100 Message-ID: References: <87y25jo2q1.fsf@web.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000089b44205d13b4052" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2461"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mattiase@acm.org, Stefan Monnier , 51982@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 20 17:56:26 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1moTf8-0000Tq-0V for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 20 Nov 2021 17:56:26 +0100 Original-Received: from localhost ([::1]:38030 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1moTf6-0006zp-5L for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 20 Nov 2021 11:56:24 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57200) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moTem-0006vU-FH for bug-gnu-emacs@gnu.org; Sat, 20 Nov 2021 11:56:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60261) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1moTej-00066q-Uf for bug-gnu-emacs@gnu.org; Sat, 20 Nov 2021 11:56:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1moTej-0003dg-M7 for bug-gnu-emacs@gnu.org; Sat, 20 Nov 2021 11:56:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Nov 2021 16:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51982 X-GNU-PR-Package: emacs Original-Received: via spool by 51982-submit@debbugs.gnu.org id=B51982.163742730813905 (code B ref 51982); Sat, 20 Nov 2021 16:56:01 +0000 Original-Received: (at 51982) by debbugs.gnu.org; 20 Nov 2021 16:55:08 +0000 Original-Received: from localhost ([127.0.0.1]:43574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moTds-0003cD-5P for submit@debbugs.gnu.org; Sat, 20 Nov 2021 11:55:08 -0500 Original-Received: from mail-ed1-f41.google.com ([209.85.208.41]:34559) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moTdp-0003bS-Pm for 51982@debbugs.gnu.org; Sat, 20 Nov 2021 11:55:07 -0500 Original-Received: by mail-ed1-f41.google.com with SMTP id x15so56486425edv.1 for <51982@debbugs.gnu.org>; Sat, 20 Nov 2021 08:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=chT3W6AY6X7eSZ7Zq01pSeRW0vVZtQcQ90aMn8aBjv4=; b=SUsA48eYvdVsZk+bxrB2vjmfp9VTqr5RF1/CHFXzV2lhedIH5VrvQ4afIp6Z1HKJE9 oPPHLvfgUY0poEu7O5BfPOF2rTEnPx/3jIwg5E1FAoUr9zaLxHQr+BWz3zVJw1V7w+nE jpR5pTPGWX+rDJnWU4nx4Qlab7c64sONCcua1SbVdiZ+q+r1cqmXiswzSG/CtntTeCDg V2uXG07+fHsCA+9JSrxZwTraHjP6A6Tj3MVw3RoKWJUHX9lTeFuO1H907bQPnFHCyfY6 sDw492yYDFywnAQ/bXwv4JbkHzVAQe9xbFwep7x7JYLrAWZCpvbp3yNYRTbBHBtM10Iu B2WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=chT3W6AY6X7eSZ7Zq01pSeRW0vVZtQcQ90aMn8aBjv4=; b=N2yYP1YHRXVjozycCPt4i/6E201N0xMTkKCFSw2xesIyFGoCpuGWDQKcaEdBxFj5Tz IkQyNl9QTK+2cEa1OffoZRk3p7lorc+bOmPfJ8P2IzPkFpdbQrNH73TzcwhWutgJ/mKS 6TxZO7A5LQlrBxJ/ZxAELBke0potqz70n7J7l0XzkHQwsCEeEmeB9XrPGvA2eXepxUuf 4LOF4Wg2zPVHWIzAB7UGxXVkEmLWjJorJECV/CyE89PkqYdtLJMWrQ+C0tnNBXiOjQtp 7W3iPKeJR0j3OXCCW907KxkbdzJcafZ+W71cw7x4QaA2a8LDxgLJzsHdvsRpV/Ip2eyy /7dw== X-Gm-Message-State: AOAM531R7F84rFXVYG0jVpYIkigo5QmDsCVYv6hAN445bluMRZWuOGiO Vsd10bbZ7Y4s5s6//NcB79EVh4e9A8djtHCQTg== X-Google-Smtp-Source: ABdhPJywb9GV315OGw7OsTwyhnSvgcSUnwMdYFMFo7iafQ6SrOCFpolvaDI+YHdKxreJMgKq+kzwexDf6LTXzfvxN9A= X-Received: by 2002:a17:907:2da1:: with SMTP id gt33mr20703662ejc.378.1637427299594; Sat, 20 Nov 2021 08:54:59 -0800 (PST) In-Reply-To: <87y25jo2q1.fsf@web.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:220511 Archived-At: --00000000000089b44205d13b4052 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to note: I consider this bug pretty important. The example function looks artificial, but I got the real failure by combining macros from different packages (`dash.el' for all the `it' bindings, plus `pcase' and `iter2' for lambdas, but I'm pretty sure you could get a failure with nested complicated `pcase' alone, if you want to go "only built-in" route). So, while it is apparently unlikely, you still can stumble into an incomprehensible breakdown in any sofisticated function by nesting enough macros that work otherwise and actually produce code that should work also in this case. But doesn't, when byte-compiled. Paul On Sat, 20 Nov 2021 at 05:44, Michael Heerdegen wrote: > Hello Paul, > > thanks for the report, I can reproduce the issue, there is something > going wrong when compiling. I guess this is something for Mattias or > Stefan maybe? (CC'd) > > #+begin_src emacs-lisp > ; -*- lexical-binding: t -*- > > (defun wtf (x) > (let ((it 0)) > #'(lambda () > (let ((fn #'(lambda () it))) > (if x > (let ((it x)) > it) > (funcall fn)))))) > #+end_src > > Byte compile: > > > wtf.el:9:17:Warning: reference to free variable =E2=80=98it=E2=80= =99 > > (funcall (wtf 1)) > > > Symbol=E2=80=99s value as variable is void: it > > while expected result is 1. Uncompiled code works as expected. > > TIA, > > Michael. > --00000000000089b44205d13b4052 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to note: I consider this bug pretty important. The ex= ample function looks artificial, but I got the real failure by combining ma= cros from different packages (`dash.el' for all the `it' bindings, = plus `pcase' and `iter2' for lambdas, but I'm pretty sure you c= ould get a failure with nested complicated `pcase' alone, if you want t= o go "only built-in" route). So, while it is apparently unlikely,= you still can stumble into an incomprehensible breakdown in any sofisticat= ed function by nesting enough macros that work otherwise and actually produ= ce code that should work also in this case. But doesn't, when byte-comp= iled.

Paul

On Sat, 20 Nov 2021 at 05:44, Michael He= erdegen <michael_heerdegen@w= eb.de> wrote:
Hello Paul,

thanks for the report, I can reproduce the issue, there is something
going wrong when compiling.=C2=A0 I guess this is something for Mattias or<= br> Stefan maybe? (CC'd)

#+begin_src emacs-lisp
; -*- lexical-binding: t -*-

(defun wtf (x)
=C2=A0 (let ((it 0))
=C2=A0 =C2=A0 #'(lambda ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (let ((fn #'(lambda () it)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (if x
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (let ((it x))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (funcall fn))))))
#+end_src

Byte compile:

>=C2=A0 =C2=A0 =C2=A0wtf.el:9:17:Warning: reference to free variable =E2= =80=98it=E2=80=99

(funcall (wtf 1))

>=C2=A0 =C2=A0 =C2=A0Symbol=E2=80=99s value as variable is void: it

while expected result is 1.=C2=A0 Uncompiled code works as expected.

TIA,

Michael.
--00000000000089b44205d13b4052--