From unknown Tue Jun 17 20:19:58 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#34757 <34757@debbugs.gnu.org> To: bug#34757 <34757@debbugs.gnu.org> Subject: Status: Invalid bytecode from byte compiler Reply-To: bug#34757 <34757@debbugs.gnu.org> Date: Wed, 18 Jun 2025 03:19:58 +0000 retitle 34757 Invalid bytecode from byte compiler reassign 34757 emacs submitter 34757 chuntaro severity 34757 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 05 10:29:21 2019 Received: (at submit) by debbugs.gnu.org; 5 Mar 2019 15:29:21 +0000 Received: from localhost ([127.0.0.1]:33323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h1C0O-0005km-Er for submit@debbugs.gnu.org; Tue, 05 Mar 2019 10:29:21 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38653) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h150o-0001H4-BV for submit@debbugs.gnu.org; Tue, 05 Mar 2019 03:01:18 -0500 Received: from lists.gnu.org ([209.51.188.17]:34396) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h150j-0006zC-1v for submit@debbugs.gnu.org; Tue, 05 Mar 2019 03:01:13 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h150h-0006UM-8K for bug-gnu-emacs@gnu.org; Tue, 05 Mar 2019 03:01:12 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h150d-0006su-Gv for bug-gnu-emacs@gnu.org; Tue, 05 Mar 2019 03:01:11 -0500 Received: from www1143.sakura.ne.jp ([219.94.129.183]:37231) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h150d-0006mR-07 for bug-gnu-emacs@gnu.org; Tue, 05 Mar 2019 03:01:07 -0500 Received: from fsav103.sakura.ne.jp (fsav103.sakura.ne.jp [27.133.134.230]) by www1143.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id x25811jN046750 for ; Tue, 5 Mar 2019 17:01:01 +0900 (JST) (envelope-from chuntaro@sakura-games.jp) Received: from www1143.sakura.ne.jp (219.94.129.183) by fsav103.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav103.sakura.ne.jp); Tue, 05 Mar 2019 17:01:01 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav103.sakura.ne.jp) Received: from [192.168.179.6] (KD036012103231.au-net.ne.jp [36.12.103.231]) (authenticated bits=0) by www1143.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id x25811Sn046743 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 5 Mar 2019 17:01:01 +0900 (JST) (envelope-from chuntaro@sakura-games.jp) To: bug-gnu-emacs@gnu.org From: chuntaro Subject: Invalid bytecode from byte compiler Message-ID: Date: Tue, 5 Mar 2019 17:01:00 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 219.94.129.183 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Tue, 05 Mar 2019 10:29:19 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Invalid bytecode is output and error occurs when executed. Byte compile the following code. bug.el ---------------------------------------------------------------- ;;; -*- lexical-binding: t; -*- (let ((a 2)) (print 1) (setq a 1)) ---------------------------------------------------------------- $ emacs --batch -f batch-byte-compile bug.el bug.elc ---------------------------------------------------------------- ;ELC ... ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (funcall 2 'print 1) 1 ---------------------------------------------------------------- $ emacs --batch -l bug.elc Invalid function: 2 It occurs in versions 25.2, 26.1 and HEAD. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 08 08:18:57 2019 Received: (at 34757) by debbugs.gnu.org; 8 Mar 2019 13:18:57 +0000 Received: from localhost ([127.0.0.1]:35936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h2FOr-0006ar-Bh for submit@debbugs.gnu.org; Fri, 08 Mar 2019 08:18:57 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51299) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h2FOp-0006ae-Gi for 34757@debbugs.gnu.org; Fri, 08 Mar 2019 08:18:55 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2FOi-00006n-Rf; Fri, 08 Mar 2019 08:18:48 -0500 Received: from [176.228.60.248] (port=4175 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h2FOh-0001YG-5Y; Fri, 08 Mar 2019 08:18:47 -0500 Date: Fri, 08 Mar 2019 15:18:31 +0200 Message-Id: <83k1h9a4ig.fsf@gnu.org> From: Eli Zaretskii To: chuntaro In-reply-to: (message from chuntaro on Tue, 5 Mar 2019 17:01:00 +0900) Subject: Re: bug#34757: Invalid bytecode from byte compiler References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34757 Cc: 34757@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: chuntaro > Date: Tue, 5 Mar 2019 17:01:00 +0900 > > Invalid bytecode is output and error occurs when executed. > > Byte compile the following code. > > bug.el > ---------------------------------------------------------------- > ;;; -*- lexical-binding: t; -*- > > (let ((a 2)) > (print 1) > (setq a 1)) > ---------------------------------------------------------------- > > $ emacs --batch -f batch-byte-compile bug.el > > bug.elc > ---------------------------------------------------------------- > ;ELC > ... > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > > > (funcall 2 'print 1) > 1 > ---------------------------------------------------------------- > > $ emacs --batch -l bug.elc > Invalid function: 2 Why is that a problem? The Lisp code is invalid, and the error message says that much. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 08 08:51:00 2019 Received: (at 34757) by debbugs.gnu.org; 8 Mar 2019 13:51:00 +0000 Received: from localhost ([127.0.0.1]:35965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h2Fto-0000xu-Ih for submit@debbugs.gnu.org; Fri, 08 Mar 2019 08:50:58 -0500 Received: from mout.web.de ([212.227.15.3]:45155) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h2Ftm-0000xd-7d for 34757@debbugs.gnu.org; Fri, 08 Mar 2019 08:50:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1552053036; bh=6JjrfDmxi9a6abZHKumm1CPv8NV77p8q311jjh4uVDw=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=qFSX2mnngUYhZGe8OxwVMvHPmxQICACB8XfTir2XlG9V+xP+rj4YGE1TxT8laOvr6 SvbnQZZE6vzgOXI/SuCNCEG6PKdjdIfKUebj6jlEsGDPCd8zYVYA1pcauW8G/+LKvO fqTh0GhZWsnS6ZkZdT08XJhexTbHj8eDkvINg2RA= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.111.211]) by smtp.web.de (mrweb004 [213.165.67.108]) with ESMTPSA (Nemesis) id 0Lr59f-1gXIfH16Ml-00eazy; Fri, 08 Mar 2019 14:50:36 +0100 From: Michael Heerdegen To: Eli Zaretskii Subject: Re: bug#34757: Invalid bytecode from byte compiler References: <83k1h9a4ig.fsf@gnu.org> Date: Fri, 08 Mar 2019 14:50:33 +0100 In-Reply-To: <83k1h9a4ig.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 08 Mar 2019 15:18:31 +0200") Message-ID: <871s3ho4pi.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:MVFNV6qjHd06+7CnmcJFMpg/On807iTKAtZr1O+YOi0QIyEWkxK yIatWcMa8JSx4x79rdy5T1aQTjDSlY7UxSnM0r+kJcPJZzI1o9AR34DL4tPe2ROQGytCl8y nqhSmKYvY52c6t3nN3KE1AcUBeSexqIkaYqSJv/8PaGYkT0VMrivAlbNKrANrSPo0VEPxvl oBiV22rKlEeqD/bncvVEg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:vs/Q5DIPTK0=:4dJetnz23wSCvCHZVesIz2 bFXjdJMC8+1AsV73SBDPJ0T9J5ZoCdejwPP1qx+4oQjdS3Vx4PI9TqqVROKXTUhSCWfnxYml0 ZsMsC5XxcXDnc5jm72McLhy/FrUAIH3++P7Vp5cxLKfAZHq6+dOeYKrS5pTAqsK6UcPcRchIw T8uC31n7cv1fbajkUf2PUDSRKPk2j5mwH+k0EXtQzMl6Mf2O/SI3Gaajo7vkbPYOc9KInxu4B xE2AuePGppq14QSg0rtNHD+MllLTWI7tU7nn4U334LdUFPCn+bn67GSylH6eGEfCRy9prhMAD a4ATuzfgaEkJnA6UnfVc9oEhqmyH/YrYg18oJvIn99zrGAySEIpUC+hamRXgAu/EH8DeS+988 F6lxqHB5HgusR56cNtnnwKWjN1zJarBMqpjLrLpw1EZZfUUn714AMrMA7yj1LL1pV89R5w2VX i+0mvbsdBkJDi1g1iv8oesyT3NFRTI/SrTJySpG5qbWQwxtuKqvon+RdDMwNDohGUkIpdtdJ5 kznV+5dy6DRBUaefZh0FWqxu5MM1hcwvaa1Bmbfl59r6SgdarR2W4wO3B8RhfdMx41as2Do5h r1xxPCCzKTVVwlWCIVBbsEYWFGdbT2ydAk2eSbkr4nT/xLb6T8VezrBC2a6Ht9pEx/nZLNDXO mJkzRtJKkn1clujWdqqFDFFyrw1+IVmjExQk33Cp1kzwsnNtwl16ZQ7UeF2QBvGcMziQ5iNZ3 5ehYyt8VkVh069GrpY79TcKg936NIGyrHwSWuewOppDbsIJRxth2Wd8+pEQoi2nQXvzzXNx+2 nJWPUhuJmBATslFHdHUdpUADP5bSvC4j2vQ+v1YR+dikYmU1dhp0yBFFHlumz6mGD4BASfJSj sDz1wrSuY1N5mNlhFgxwVcNBxVM3hemafwGmupaaVo1PwhZMNdwXP3vPM5GUH1J1CKKZW7gFx xdFnY1FbkUQ== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34757 Cc: 34757@debbugs.gnu.org, chuntaro X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: > > From: chuntaro > > Date: Tue, 5 Mar 2019 17:01:00 +0900 > > > > Invalid bytecode is output and error occurs when executed. > > > > Byte compile the following code. > > > > bug.el > > ---------------------------------------------------------------- > > ;;; -*- lexical-binding: t; -*- > > > > (let ((a 2)) > > (print 1) > > (setq a 1)) > > ---------------------------------------------------------------- > > > > $ emacs --batch -f batch-byte-compile bug.el > > > > bug.elc > > ---------------------------------------------------------------- > > ;ELC > > ... > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > > > > > > (funcall 2 'print 1) > > 1 > > ---------------------------------------------------------------- > > > > $ emacs --batch -l bug.elc > > Invalid function: 2 > > Why is that a problem? The Lisp code is invalid, and the error > message says that much. Please take a closer look: The Lisp code in the compiled file is invalid, but the code in the .el isn't. Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 08 09:36:30 2019 Received: (at 34757) by debbugs.gnu.org; 8 Mar 2019 14:36:30 +0000 Received: from localhost ([127.0.0.1]:35975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h2Gbu-00027K-Hd for submit@debbugs.gnu.org; Fri, 08 Mar 2019 09:36:30 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h2Gbs-000275-HS for 34757@debbugs.gnu.org; Fri, 08 Mar 2019 09:36:28 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2Gbk-0003ls-Vt; Fri, 08 Mar 2019 09:36:21 -0500 Received: from [176.228.60.248] (port=1149 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h2Gbk-0004oC-0L; Fri, 08 Mar 2019 09:36:20 -0500 Date: Fri, 08 Mar 2019 16:36:04 +0200 Message-Id: <83ef7ha0x7.fsf@gnu.org> From: Eli Zaretskii To: Michael Heerdegen In-reply-to: <871s3ho4pi.fsf@web.de> (message from Michael Heerdegen on Fri, 08 Mar 2019 14:50:33 +0100) Subject: Re: bug#34757: Invalid bytecode from byte compiler References: <83k1h9a4ig.fsf@gnu.org> <871s3ho4pi.fsf@web.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34757 Cc: 34757@debbugs.gnu.org, chuntaro@sakura-games.jp X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Michael Heerdegen > Cc: chuntaro , 34757@debbugs.gnu.org > Date: Fri, 08 Mar 2019 14:50:33 +0100 > > Please take a closer look: The Lisp code in the compiled file is > invalid, but the code in the .el isn't. Right, sorry for my confusion. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 08 16:14:25 2019 Received: (at 34757) by debbugs.gnu.org; 8 Mar 2019 21:14:25 +0000 Received: from localhost ([127.0.0.1]:36766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h2Moy-0004eZ-Qo for submit@debbugs.gnu.org; Fri, 08 Mar 2019 16:14:25 -0500 Received: from mail-ot1-f48.google.com ([209.85.210.48]:43480) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h2Mou-0004eG-Ra for 34757@debbugs.gnu.org; Fri, 08 Mar 2019 16:14:22 -0500 Received: by mail-ot1-f48.google.com with SMTP id n71so18566685ota.10 for <34757@debbugs.gnu.org>; Fri, 08 Mar 2019 13:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Em1deGWKgGAduZCFbinna9ZMIEVr2aTUrUU9sZ7GJd0=; b=UZLBqjYAKKFg8ZCjZa1wQTSVFOLN7NyQpbSi0vHtiTawhewaO2QBQ8Hach1WSpY87e gtzX4taD1SMM6OWzO2lQfs61pvhKY/z6aT0AHpp1H5wZGtrHvbgwLvW9dFU9VS+25asE adER7QDuwWyJA3bypgU+hkwegUF0DleM3nkK3yY70gDOSeUOk2IQDfWaxKMA7FCsWVBk S5rN4LrsZYWgNfN6wfdpbxBdDwQykwGcyt73f3e8u40KmxLFVu2XMrUe1BxWXgUlU4dn Zf3kw1JeUCmqNZinrjQqB6zEsEpapLyZH7gRV05CMJ3LL4Cpy1VTGkGwSIh9i0NlqGQt fDNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Em1deGWKgGAduZCFbinna9ZMIEVr2aTUrUU9sZ7GJd0=; b=sL92FLpP/zWW86kdjx0VoJzNJBD44mTGo3sMh+Vwi42z3iVBn1LU3Rbu+z1RPLMkI5 ytUVREEte3ppFz1Q4JUtDrbQlQh5+jtEL9/Bs2TI33PQAW0Sjk9nObz4T6eQ/YD0KX32 5rOV2t/pealTTVA2HDzON7FzkBX+vBY1D9LTTSDtlBMjpYx1FuZM2o/yoJvfUk32Zykd 0/DnkvLzrA7tT7XdFu2LWIYb9DKTt2msQVrh3w77uGn3zAFfKOxXc5HK4wV6q/R+Vg+I crUgmsNufiLzcMeuV2kZXyAmIWkQ66/MPxBKQMn9z1D2KIz8Las6X3gqFfwTcjYAsG74 H7MA== X-Gm-Message-State: APjAAAVFegzsUgfVSsQTIfQSp1t8AcnpXAztYIQkp1P5GAwJRjQxTJ/f 6JXkPmOkDPOwAE+JOh9hU+jrJHO5QiMvJHqnASsJi4nA X-Google-Smtp-Source: APXvYqw6GrdZhPVR/7uanArjIRD8QRRVS7DF2PB820P7yRETrnTZeFx2s1sGjZ+S2P3EZ1bkQW2FTSlSiZdW/ijCPxA= X-Received: by 2002:a9d:66c8:: with SMTP id t8mr12226694otm.368.1552079655067; Fri, 08 Mar 2019 13:14:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pip Cet Date: Fri, 8 Mar 2019 21:13:37 +0000 Message-ID: Subject: Re: bug#34757: Invalid bytecode from byte compiler To: chuntaro Content-Type: multipart/mixed; boundary="000000000000813db605839bb438" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34757 Cc: 34757@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000813db605839bb438 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 5, 2019 at 3:30 PM chuntaro wrote: > > Invalid bytecode is output and error occurs when executed. If I'm looking at this correctly, the problem is that the byte code which is generated in an intermediate step: 0 constant 2 1 constant print 2 constant 1 3 call 1 4 discard 5 constant 3 6 return is considered a "trivial function" by byte-compile-out-toplevel, which assumes that all values on the stack are used by the call. We could fix byte-compile-out-toplevel to properly analyze how many stack arguments the call takes, but this patch simply treats forms like this as nontrivial: diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index 0b8f8824b4c..4e54e08ce14 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -3025,6 +3025,7 @@ byte-compile-out-toplevel (or (null (cdr rest)) (and (memq output-type '(file progn t)) (cdr (cdr rest)) + (eql (length body) (cdr (car rest))) (eq (car (nth 1 rest)) 'byte-discard) (progn (setq rest (cdr rest)) t)))) (setq maycall nil) ; Only allow one real function call. --000000000000813db605839bb438 Content-Type: text/x-patch; charset="US-ASCII"; name="emacs-34757.diff" Content-Disposition: attachment; filename="emacs-34757.diff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jt0k06le0 ZGlmZiAtLWdpdCBhL2xpc3AvZW1hY3MtbGlzcC9ieXRlY29tcC5lbCBiL2xpc3AvZW1hY3MtbGlz cC9ieXRlY29tcC5lbAppbmRleCAwYjhmODgyNGI0Yy4uNGU1NGUwOGNlMTQgMTAwNjQ0Ci0tLSBh L2xpc3AvZW1hY3MtbGlzcC9ieXRlY29tcC5lbAorKysgYi9saXNwL2VtYWNzLWxpc3AvYnl0ZWNv bXAuZWwKQEAgLTMwMjUsNiArMzAyNSw3IEBAIGJ5dGUtY29tcGlsZS1vdXQtdG9wbGV2ZWwKICAg ICAgICAgICAgICAgICAgICAgICAgKG9yIChudWxsIChjZHIgcmVzdCkpCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAoYW5kIChtZW1xIG91dHB1dC10eXBlICcoZmlsZSBwcm9nbiB0KSkKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNkciAoY2RyIHJlc3QpKQorICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAoZXFsIChsZW5ndGggYm9keSkgKGNkciAoY2FyIHJlc3Qp KSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGVxIChjYXIgKG50aCAxIHJlc3Qp KSAnYnl0ZS1kaXNjYXJkKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAocHJvZ24g KHNldHEgcmVzdCAoY2RyIHJlc3QpKSB0KSkpKQogICAgICAgICAgICAgICAgICAgKHNldHEgbWF5 Y2FsbCBuaWwpCTsgT25seSBhbGxvdyBvbmUgcmVhbCBmdW5jdGlvbiBjYWxsLgo= --000000000000813db605839bb438-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 15 04:08:40 2019 Received: (at 34757) by debbugs.gnu.org; 15 Mar 2019 08:08:40 +0000 Received: from localhost ([127.0.0.1]:44350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4htN-0001LZ-So for submit@debbugs.gnu.org; Fri, 15 Mar 2019 04:08:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53631) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4htL-0001LN-W5 for 34757@debbugs.gnu.org; Fri, 15 Mar 2019 04:08:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52098) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4htG-0002Mq-2R; Fri, 15 Mar 2019 04:08:30 -0400 Received: from [176.228.60.248] (port=2093 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h4htF-0000sz-8S; Fri, 15 Mar 2019 04:08:29 -0400 Date: Fri, 15 Mar 2019 10:08:12 +0200 Message-Id: <838sxg1rwz.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet , Stefan Monnier In-reply-to: (message from Pip Cet on Fri, 8 Mar 2019 21:13:37 +0000) Subject: Re: bug#34757: Invalid bytecode from byte compiler References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34757 Cc: 34757@debbugs.gnu.org, chuntaro@sakura-games.jp X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Pip Cet > Date: Fri, 8 Mar 2019 21:13:37 +0000 > Cc: 34757@debbugs.gnu.org > > On Tue, Mar 5, 2019 at 3:30 PM chuntaro wrote: > > > > Invalid bytecode is output and error occurs when executed. > > If I'm looking at this correctly, the problem is that the byte code > which is generated in an intermediate step: > > 0 constant 2 > 1 constant print > 2 constant 1 > 3 call 1 > 4 discard > 5 constant 3 > 6 return > > is considered a "trivial function" by byte-compile-out-toplevel, which > assumes that all values on the stack are used by the call. > > We could fix byte-compile-out-toplevel to properly analyze how many > stack arguments the call takes, but this patch simply treats forms > like this as nontrivial: > > diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el > index 0b8f8824b4c..4e54e08ce14 100644 > --- a/lisp/emacs-lisp/bytecomp.el > +++ b/lisp/emacs-lisp/bytecomp.el > @@ -3025,6 +3025,7 @@ byte-compile-out-toplevel > (or (null (cdr rest)) > (and (memq output-type '(file progn t)) > (cdr (cdr rest)) > + (eql (length body) (cdr (car rest))) > (eq (car (nth 1 rest)) 'byte-discard) > (progn (setq rest (cdr rest)) t)))) > (setq maycall nil) ; Only allow one real function call. Stefan, any comments? From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 15 10:08:56 2019 Received: (at 34757) by debbugs.gnu.org; 15 Mar 2019 14:08:56 +0000 Received: from localhost ([127.0.0.1]:45300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4nW3-0004Cg-Ko for submit@debbugs.gnu.org; Fri, 15 Mar 2019 10:08:56 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:56262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4nW0-0004CW-3v for 34757@debbugs.gnu.org; Fri, 15 Mar 2019 10:08:54 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x2FE8mbl031869; Fri, 15 Mar 2019 10:08:49 -0400 Received: by pastel.home (Postfix, from userid 20848) id BA1EC6AB8D; Fri, 15 Mar 2019 10:08:48 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#34757: Invalid bytecode from byte compiler Message-ID: References: <838sxg1rwz.fsf@gnu.org> Date: Fri, 15 Mar 2019 10:08:48 -0400 In-Reply-To: <838sxg1rwz.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Mar 2019 10:08:12 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6504=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6504> : inlines <7034> : streams <1815782> : uri <2813266> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34757 Cc: chuntaro@sakura-games.jp, Pip Cet , 34757@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el >> index 0b8f8824b4c..4e54e08ce14 100644 >> --- a/lisp/emacs-lisp/bytecomp.el >> +++ b/lisp/emacs-lisp/bytecomp.el >> @@ -3025,6 +3025,7 @@ byte-compile-out-toplevel >> (or (null (cdr rest)) >> (and (memq output-type '(file progn t)) >> (cdr (cdr rest)) >> + (eql (length body) (cdr (car rest))) >> (eq (car (nth 1 rest)) 'byte-discard) >> (progn (setq rest (cdr rest)) t)))) >> (setq maycall nil) ; Only allow one real function call. > > Stefan, any comments? Looks good to me, thanks. I'm personally running with the following patch instead, which is much more risky and hasn't been sufficiently tested yet. Stefan diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index f46cab2c17..573b0489d4 100644 *** a/lisp/emacs-lisp/bytecomp.el --- b/lisp/emacs-lisp/bytecomp.el *************** *** 2990,3059 **** (setq byte-compile-output (byte-optimize-lapcode byte-compile-output))) ! ;; Decompile trivial functions: ! ;; only constants and variables, or a single funcall except in lambdas. ! ;; Except for Lisp_Compiled objects, forms like (foo "hi") ! ;; are still quicker than (byte-code "..." [foo "hi"] 2). ! ;; Note that even (quote foo) must be parsed just as any subr by the ! ;; interpreter, so quote should be compiled into byte-code in some contexts. ! ;; What to leave uncompiled: ! ;; lambda -> never. we used to leave it uncompiled if the body was ! ;; a single atom, but that causes confusion if the docstring ! ;; uses the (file . pos) syntax. Besides, now that we have ! ;; the Lisp_Compiled type, the compiled form is faster. ! ;; eval -> atom, quote or (function atom atom atom) ! ;; progn -> as <> or (progn <> atom) ! ;; file -> as progn, but takes both quotes and atoms, and longer forms. ! (let (rest ! (maycall (not (eq output-type 'lambda))) ; t if we may make a funcall. ! tmp body) ! (cond ! ;; #### This should be split out into byte-compile-nontrivial-function-p. ! ((or (eq output-type 'lambda) ! (nthcdr (if (eq output-type 'file) 50 8) byte-compile-output) ! (assq 'TAG byte-compile-output) ; Not necessary, but speeds up a bit. ! (not (setq tmp (assq 'byte-return byte-compile-output))) ! (progn ! (setq rest (nreverse ! (cdr (memq tmp (reverse byte-compile-output))))) ! (while ! (cond ! ((memq (car (car rest)) '(byte-varref byte-constant)) ! (setq tmp (car (cdr (car rest)))) ! (if (if (eq (car (car rest)) 'byte-constant) ! (or (consp tmp) ! (and (symbolp tmp) ! (not (macroexp--const-symbol-p tmp))))) ! (if maycall ! (setq body (cons (list 'quote tmp) body))) ! (setq body (cons tmp body)))) ! ((and maycall ! ;; Allow a funcall if at most one atom follows it. ! (null (nthcdr 3 rest)) ! (setq tmp (get (car (car rest)) 'byte-opcode-invert)) ! (or (null (cdr rest)) ! (and (memq output-type '(file progn t)) ! (cdr (cdr rest)) ! (eq (car (nth 1 rest)) 'byte-discard) ! (progn (setq rest (cdr rest)) t)))) ! (setq maycall nil) ; Only allow one real function call. ! (setq body (nreverse body)) ! (setq body (list ! (if (and (eq tmp 'funcall) ! (eq (car-safe (car body)) 'quote) ! (symbolp (nth 1 (car body)))) ! (cons (nth 1 (car body)) (cdr body)) ! (cons tmp body)))) ! (or (eq output-type 'file) ! (not (delq nil (mapcar 'consp (cdr (car body)))))))) ! (setq rest (cdr rest))) ! rest)) ! (let ((byte-compile-vector (byte-compile-constants-vector))) ! (list 'byte-code (byte-compile-lapcode byte-compile-output) ! byte-compile-vector byte-compile-maxdepth))) ! ;; it's a trivial function ! ((cdr body) (cons 'progn (nreverse body))) ! ((car body))))) ;; Given BODY, compile it and return a new body. (defun byte-compile-top-level-body (body &optional for-effect) --- 2993,3013 ---- (setq byte-compile-output (byte-optimize-lapcode byte-compile-output))) ! (cond ! ((and (not (eq output-type 'lambda)) ;;The caller really wants (byte-code ...) ! (null (cddr byte-compile-output)) ! (eq (car (nth 0 byte-compile-output)) 'byte-constant) ! (eq (car (nth 1 byte-compile-output)) 'byte-return)) ! ;; Special case for trivial code returning a function. ! ;; This is so that when compiling #'(lambda ...) we return ! ;; a #[...] byte-code object instead of a (byte-code "...") ! ;; expression that returns this object. It's not indispensable, ! ;; but it's cleaner. ! (macroexp-quote (cadr (nth 0 byte-compile-output)))) ! (t ! (let ((byte-compile-vector (byte-compile-constants-vector))) ! (list 'byte-code (byte-compile-lapcode byte-compile-output) ! byte-compile-vector byte-compile-maxdepth))))) ;; Given BODY, compile it and return a new body. (defun byte-compile-top-level-body (body &optional for-effect) From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 15 15:41:37 2019 Received: (at 34757) by debbugs.gnu.org; 15 Mar 2019 19:41:37 +0000 Received: from localhost ([127.0.0.1]:45524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4si0-00010v-Nn for submit@debbugs.gnu.org; Fri, 15 Mar 2019 15:41:36 -0400 Received: from mail-oi1-f173.google.com ([209.85.167.173]:44151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4shw-00010f-E3 for 34757@debbugs.gnu.org; Fri, 15 Mar 2019 15:41:32 -0400 Received: by mail-oi1-f173.google.com with SMTP id i21so4895887oib.11 for <34757@debbugs.gnu.org>; Fri, 15 Mar 2019 12:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c4OyfsASyRybHwSQ1ljQHW70WpfWVL11rds6eZLlyus=; b=pOZ/UN6nYfICPEVjld/ilJb82m2CdIJS2796jocNEwq/tuEziPP7HifLhJqGDg7lWc oqYYppycGFZvjjnHTbklHVzbogp3LRCHnB/eJfkKVRQPPMQ1g0iFlYb5dq1M8ruZwWUH CvxrOIa/uLuP4JanfmKSo2rqdqCuidAeJlANC25G9ubuxbzvobvjAdHzQ6FwN8fQzX5F yqD805O3H22Z6PJ++4EPK3Hv+R5GF05P5N0NoRsldaC9DotLts9W7Tk1jXUy40kAEGnN EDFsIisaE/5QcvH96ERXE34/y1g90C2WqcWuHZbxNqPdsa+S14RdkseTmiEOYzI9+Cae M3Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c4OyfsASyRybHwSQ1ljQHW70WpfWVL11rds6eZLlyus=; b=chjPHdaBL1wXZQ67jB9QjLOmUQ58rAMj2VWBshHHWsiu1QcZlSxGsERI0wJLhwc2hl oSps64cLsPhJ2LTAUOdCZtHapz/Ims4WZjLZ1LTaeKC0yo3weUJrTl2GyMYSb+1RuwB6 BLk8xNuJOBMQESZzGtWEvJU0HzHvA2KkeNXoq3rhjXmdLOEywUacYVkrpmVBv1qg3M7W nlqaMZCZndq6Bz4vss2w+mE8BNpj71pkFkgmRjU//H2zuPJenaRAwFtajw21to5sZ3Gy Lo5wQO/jV3JQthfynhNoRGwc/EsDVsmMGcgF//jutdt26q/ZK+ym50hyyO5wE1glX5+T nZxQ== X-Gm-Message-State: APjAAAVWoqTln9i2UD5EpHuTEFY3kG0J53z4Au2W+Z67uOB1798mSPAX wEnNb7BfEkr3Bot1hArABYPzE9JX3CeaeD+Jdgg= X-Google-Smtp-Source: APXvYqze5efRsShp1w8O9pxRovhYWg0xmnAqvPdA0cvZh3XKDZHd+yFvTGCO9vSfAQPMzd7I0/Z0lNCaMB3jqxdblBY= X-Received: by 2002:aca:52c2:: with SMTP id g185mr2682582oib.128.1552678886581; Fri, 15 Mar 2019 12:41:26 -0700 (PDT) MIME-Version: 1.0 References: <838sxg1rwz.fsf@gnu.org> In-Reply-To: From: Pip Cet Date: Fri, 15 Mar 2019 19:40:48 +0000 Message-ID: Subject: Re: bug#34757: Invalid bytecode from byte compiler To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34757 Cc: Eli Zaretskii , chuntaro@sakura-games.jp, 34757@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Mar 15, 2019 at 2:08 PM Stefan Monnier wrote: > >> diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el > >> index 0b8f8824b4c..4e54e08ce14 100644 > >> --- a/lisp/emacs-lisp/bytecomp.el > >> +++ b/lisp/emacs-lisp/bytecomp.el > >> @@ -3025,6 +3025,7 @@ byte-compile-out-toplevel > >> (or (null (cdr rest)) > >> (and (memq output-type '(file progn t)) > >> (cdr (cdr rest)) > >> + (eql (length body) (cdr (car rest))) > >> (eq (car (nth 1 rest)) 'byte-discard) > >> (progn (setq rest (cdr rest)) t)))) > >> (setq maycall nil) ; Only allow one real function call. > > > > Stefan, any comments? > > Looks good to me, thanks. > > I'm personally running with the following patch instead, which is much > more risky and hasn't been sufficiently tested yet. Just to be sure I understand correctly, you would like to remove the decompilation of trivial function calls entirely? That seems good to me. It seems the special case is necessary to avoid compilation errors, and that it's used for (byte-compile 3), so I think the comment could be improved a little. I'm not sure this case can actually happen without doing something silly, but (byte-compile '(internal-get-closed-var 0)) throws an error with Stefan's patch, because the byte code is (byte-constant . 0) (byte-return). From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 15 16:30:16 2019 Received: (at 34757) by debbugs.gnu.org; 15 Mar 2019 20:30:16 +0000 Received: from localhost ([127.0.0.1]:45532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4tT6-0002BT-4P for submit@debbugs.gnu.org; Fri, 15 Mar 2019 16:30:16 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:46868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4tT3-0002BI-IM for 34757@debbugs.gnu.org; Fri, 15 Mar 2019 16:30:15 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x2FKUBr3001469; Fri, 15 Mar 2019 16:30:11 -0400 Received: by pastel.home (Postfix, from userid 20848) id F11F36AB95; Fri, 15 Mar 2019 16:30:10 -0400 (EDT) From: Stefan Monnier To: Pip Cet Subject: Re: bug#34757: Invalid bytecode from byte compiler Message-ID: References: <838sxg1rwz.fsf@gnu.org> Date: Fri, 15 Mar 2019 16:30:10 -0400 In-Reply-To: (Pip Cet's message of "Fri, 15 Mar 2019 19:40:48 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6504=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6504> : inlines <7035> : streams <1815807> : uri <2813474> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34757 Cc: Eli Zaretskii , chuntaro@sakura-games.jp, 34757@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Just to be sure I understand correctly, you would like to remove the > decompilation of trivial function calls entirely? Yes, tho the main motivation was to try and figure out what the decompilation is useful for. This only affects "open code" (i.e. not the content of functions, which are already never decompiled), so the impact should be minor and it removes a rather complicated and brittle chunk of code whose purpose is not clear. It was originally introduced when we didn't have byte-compiled function objects, so its main purpose was one of performance, to avoid pessimizing the code by replacing trivial function calls with more costly (byte-code "...") expressions but nowadays such (byte-code "...") expressions only occur basically at the top-level of .elc files where such pessimization would be unnoticeable in terms of performance. It does impact the readability of .elc files, OTOH, so I'm not completely happy with the result when considering the few cases where I was happy to be able to make sense of a .elc file to better understand the source of a problem (after all, that's why I wrote the elisp-byte-code-mode). > It seems the special case is necessary to avoid compilation errors, I haven't found it to be really necessary, no. > and that it's used for (byte-compile 3), so I think the comment could > be improved a little. (byte-compile 3) seems to work correctly here even without the special case. It returns (byte-code "\300\207" [3] 1) which is indeed a correct expression that evaluates to 3 (just like the argument to `byte-compile` was an expression whose evaluation returns 3). Let's not forget that what `byte-compile` tries to do is to preserve the invariant that (eval EXP) =E2=89=83 (eval (byte-compile EXP)) This said, if you remove the special case, you will bump into a corner-case bug in `byte-compile` which happens because that function incorrectly considers that `byte-compile-top-level` returns a value whereas in reality it returns an expression (just like `byte-compile`): the decompilation happens to turn expressions that return constant values (like byte-compiled functions) into their value (as an optimization which relies on the fact that those objects are self-evaluating), so if you remove it, you then bump into this bug of byte-compile. The patch below would fix this bug. But indeed the decompilation of constants is handy since that's what people expect from `byte-compile`. When I (byte-compile '(lambda (x) (foo))) I expect to receive a byte-compiled function, and not a byte-code expression which when evaluated will return that byte-compiled function. > I'm not sure this case can actually happen without doing something > silly, but (byte-compile '(internal-get-closed-var 0)) throws an error > with Stefan's patch, because the byte code is (byte-constant . 0) > (byte-return). This source code is arguably invalid, so it's not a real problem, but indeed we should burp in that case. I can't remember enough of how internal-get-closed-var is handled to know where'd the bug be, offhand. Stefan diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index f46cab2c17..ae17553d0c 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -2674,7 +2674,11 @@ byte-compile (setq fun (byte-compile-top-level fun nil 'eval))) (if macro (push 'macro fun)) (if (symbolp form) - (fset form fun) + ;; byte-compile returns an *expression* equivalent to the + ;; `fun' expression, so we need to evaluate it, tho normally + ;; this is not needed because the expression is just a constant + ;; byte-code object, which is self-evaluating. + (fset form (eval fun t)) fun))))))) =20 (defun byte-compile-sexp (sexp) From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 16 12:52:01 2019 Received: (at 34757) by debbugs.gnu.org; 16 Mar 2019 16:52:01 +0000 Received: from localhost ([127.0.0.1]:46681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5CXQ-0000sd-VW for submit@debbugs.gnu.org; Sat, 16 Mar 2019 12:52:01 -0400 Received: from mail-oi1-f171.google.com ([209.85.167.171]:40262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5CXO-0000sQ-QR for 34757@debbugs.gnu.org; Sat, 16 Mar 2019 12:51:59 -0400 Received: by mail-oi1-f171.google.com with SMTP id k11so9836563oic.7 for <34757@debbugs.gnu.org>; Sat, 16 Mar 2019 09:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JJbZUwDdAyc0RGBXgUnl0KyKRUxLKaCxdQimQsQhP5o=; b=q09z6MAGhci9X50N91BljshZAECMRK1j38cg+Y584Lgfjgw3WK8cxEabHu3RGqiRBB R6kXQQgnOvq0uKBnubmQFMqZF3nJ1eUZgyU50b144jRlx/JoAJp012VfljSNbDyn0vlJ oaUmIw2O1B9ePOtZ3JFq6AXY2nEd4wWI5haOiAv3okc9ddoF4Hp+82MK2RYvP8xweJ2q kz4hmISE4lFvtawnV1xwpura6bOboVfsH7Ti/Yl+D4O8ny65IEdr40+IsWOY/xMQlHRf Clzdk9Npd0FRyEsAdqax7TvySUNdUrayeRnjMPxum4xQId+nmaYmlas+ARioGVmpASPZ dVog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JJbZUwDdAyc0RGBXgUnl0KyKRUxLKaCxdQimQsQhP5o=; b=WJrBMHhGQs1crbgx6zQQ9MWPFpqUdee5awRFc7GwSEMmk02kHYyGh+VoitYm+dNQur QPmOyehqPicBm0KzdFnUq5vIjDaMh2woGRAi2ykmFYOZ8kEC3UipzcYNgWIW06UPWOQ3 mw78Mdl7uQZC2t5PLH6I+T+siPRG472Ye7sZJx9zjcVsTID7FxxNRBN8nkc7uUlz5ye4 lggWa7wSmpp6r6Epw/6sslt75qb0zYiLdV1td+fZTfG72whnLOFHc6lpJxsZscLd0342 PqkJ8GBwJxwG0HC8VTmgbRNUT+wVnAqlO171p30WibiADvm0ii2fILijKqp4U1gLkb4+ bIDQ== X-Gm-Message-State: APjAAAWwi9MdRgfjOAcnuvW3Dyk9eWHXAC4g7UWK+T1uKv4KOJ/550z1 w/f7rfidmXPaHFsYDZzMB6l+n05xs5+aGEymrtZf8A== X-Google-Smtp-Source: APXvYqw3HkM1qhw+oCiltPR9k/ilTgTVsnC8qAWKHWyBcF2kVnB2mMivIXpL3YhfMm4i2dTA7D9vADitiNwEKszzk20= X-Received: by 2002:aca:52c2:: with SMTP id g185mr5147063oib.128.1552755111824; Sat, 16 Mar 2019 09:51:51 -0700 (PDT) MIME-Version: 1.0 References: <838sxg1rwz.fsf@gnu.org> In-Reply-To: From: Pip Cet Date: Sat, 16 Mar 2019 16:51:13 +0000 Message-ID: Subject: Re: bug#34757: Invalid bytecode from byte compiler To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34757 Cc: Eli Zaretskii , chuntaro@sakura-games.jp, 34757@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Mar 15, 2019 at 8:30 PM Stefan Monnier w= rote: > > > Just to be sure I understand correctly, you would like to remove the > > decompilation of trivial function calls entirely? > > Yes, tho the main motivation was to try and figure out what the > decompilation is useful for. Thanks for explaining! > This only affects "open code" (i.e. not the content of functions, which > are already never decompiled), so the impact should be minor and it > removes a rather complicated and brittle chunk of code whose purpose is > not clear. It was originally introduced when we didn't have > byte-compiled function objects, so its main purpose was one of > performance, to avoid pessimizing the code by replacing trivial function > calls with more costly (byte-code "...") expressions but nowadays such > (byte-code "...") expressions only occur basically at the top-level of > .elc files where such pessimization would be unnoticeable in terms > of performance. I agree completely, for what it's worth. > It does impact the readability of .elc files, OTOH, so I'm not > completely happy with the result when considering the few cases where > I was happy to be able to make sense of a .elc file to better understand > the source of a problem (after all, that's why I wrote the > elisp-byte-code-mode). I can speak only for myself, but I think the byte-compiler "magically" deciding to turn (rare) top-level non-defuns into plain code rather than byte code is confusing. It's much better with your patches. > > It seems the special case is necessary to avoid compilation errors, > > I haven't found it to be really necessary, no. Well, you fixed it with the second patch. > > and that it's used for (byte-compile 3), so I think the comment could > > be improved a little. > > (byte-compile 3) seems to work correctly here even without the > special case. It returns (byte-code "\300\207" [3] 1) which is indeed > a correct expression that evaluates to 3 (just like the argument to > `byte-compile` was an expression whose evaluation returns 3). No argument here. The case branch affects what happens when (byte-compile 3) is called, but isn't necessary for the result to be correct, and the comment can be misread to imply it's irrelevant in this case. > Let's not forget that what `byte-compile` tries to do is to preserve the > invariant that > > (eval EXP) =E2=89=83 (eval (byte-compile EXP)) I think byte-compile does different things for different arguments: the behavior for symbols and other expressions is simply different. > This said, if you remove the special case, you will bump into > a corner-case bug in `byte-compile` which happens because that function > incorrectly considers that `byte-compile-top-level` returns a value > whereas in reality it returns an expression (just like `byte-compile`): > the decompilation happens to turn expressions that return constant > values (like byte-compiled functions) into their value (as an > optimization which relies on the fact that those objects are > self-evaluating), so if you remove it, you then bump into this bug of > byte-compile. The patch below would fix this bug. I don't think that was a bug, but it was an unfortunate wrinkle in the (undocumented) API of byte-compile-top-level. > But indeed the decompilation of constants is handy since that's what > people expect from `byte-compile`. When I (byte-compile '(lambda (x) > (foo))) I expect to receive a byte-compiled function, and not > a byte-code expression which when evaluated will return that > byte-compiled function. I think it's more than handy: it's how I'd read the current documentation, and how I'd expect a function called byte-compile to behave. > > I'm not sure this case can actually happen without doing something > > silly, but (byte-compile '(internal-get-closed-var 0)) throws an error > > with Stefan's patch, because the byte code is (byte-constant . 0) > > (byte-return). > > This source code is arguably invalid, so it's not a real problem, but The source code is invalid, but the LAP code is valid-looking, and I can't conclude it cannot be generated by valid source code being passed to `byte-compile' somehow. > diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el > index f46cab2c17..ae17553d0c 100644 > --- a/lisp/emacs-lisp/bytecomp.el > +++ b/lisp/emacs-lisp/bytecomp.el > @@ -2674,7 +2674,11 @@ byte-compile > (setq fun (byte-compile-top-level fun nil 'eval))) > (if macro (push 'macro fun)) > (if (symbolp form) > - (fset form fun) > + ;; byte-compile returns an *expression* equivalent to the I think this would be clearer if it read "byte-compile-top-level returns an *expression*..." From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 13 07:44:52 2019 Received: (at 34757) by debbugs.gnu.org; 13 Jun 2019 11:44:52 +0000 Received: from localhost ([127.0.0.1]:34640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hbO9z-0006cn-ND for submit@debbugs.gnu.org; Thu, 13 Jun 2019 07:44:52 -0400 Received: from mail-oi1-f170.google.com ([209.85.167.170]:40668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hbO9x-0006ca-VZ for 34757@debbugs.gnu.org; Thu, 13 Jun 2019 07:44:50 -0400 Received: by mail-oi1-f170.google.com with SMTP id w196so14177962oie.7 for <34757@debbugs.gnu.org>; Thu, 13 Jun 2019 04:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=v0jzn4cJO2lALLtB9rDiUbZYPyyHbs+FRHOnzjhTMp4=; b=Q1F2Jo4U89m2cMU7gOrozNECiU56yErzuJHNW0f37B6TuJzL+oj54iKs9q+4gYfbML WdD8VukYvR311jjJI0y4lAQUBf96dKVE+rGdjoj3LWcTNIgxUE+EqiO0qciceYv7yBRs LpAP6Y+XeljFbyFa3xo3NfK9QOpQ9lTwH/UJ/oMK+EB7GA3oIz/2QInKnWQS/AESRyDj O8xli12VvWjcyqAVsgwJ2d0NgndSo2qYqNbodSR4vQwT47Hnwdv2P+8joQ0mOfB/RXWX j1XSQ71eUN5fHdXkG5061wRjLLLLQJNVNXfpJ252Ve/gdFIoMxLHyy0ltZUWTSGjSXAI OhLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=v0jzn4cJO2lALLtB9rDiUbZYPyyHbs+FRHOnzjhTMp4=; b=Jltp6YaUHIfWdVj+5+KPnv7fqlGQ/A0s7H6urCsN7LH7pmmUG2dV9F3/MoZsR0IEN7 p2pqiTctOpLdg1beMZlojeOqFz2hyHII+BwHbEKqlNTlNcddZqq0WvsZ3GWOAt20tKJB 2YJFBHn7CHNZUFULUpz1ZI6xnpxSFdpdkpGL3GCzoB16WSHN+Lbrm8h5gywKxtHm2IS+ 0QUhH7DhuVhgUsE/faI6yd5MUZSNLS+UZZbFb7WUUtyzKO+EZarqLhUeMCrUJfPYEwHH Ht8V4igE+Zzyo4Jz2yRSp0+yQKLO2aDnqdieZhqJvpmqWxAAW13vZf5TAfthG3ahlojy g8PA== X-Gm-Message-State: APjAAAUUr/iCdPoF5dibllePFpX8qAxFC5uTzEI8thC/6H1PlA6yzdIo 5Hc4HLqFbl01KpLR9JmFREhKMWx33nWNwdZA8SI= X-Google-Smtp-Source: APXvYqwzFDUJDIg3jj13b6ZFxHzvAP0FiQE59DrSEhu2Y63gRv/2O+V5XQkTylUI8qw3q68GOA+bgODE2NyhlbZO1lI= X-Received: by 2002:aca:4790:: with SMTP id u138mr2769254oia.44.1560426284297; Thu, 13 Jun 2019 04:44:44 -0700 (PDT) MIME-Version: 1.0 References: <838sxg1rwz.fsf@gnu.org> In-Reply-To: From: Pip Cet Date: Thu, 13 Jun 2019 11:44:08 +0000 Message-ID: Subject: Re: bug#34757: Invalid bytecode from byte compiler To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34757 Cc: Eli Zaretskii , chuntaro@sakura-games.jp, 34757@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This bug still appears to be present. Maybe it's time to apply Stefan's patch and see whether anything breaks? On Sat, Mar 16, 2019 at 4:51 PM Pip Cet wrote: > > On Fri, Mar 15, 2019 at 8:30 PM Stefan Monnier = wrote: > > > > > Just to be sure I understand correctly, you would like to remove the > > > decompilation of trivial function calls entirely? > > > > Yes, tho the main motivation was to try and figure out what the > > decompilation is useful for. > > Thanks for explaining! > > > This only affects "open code" (i.e. not the content of functions, which > > are already never decompiled), so the impact should be minor and it > > removes a rather complicated and brittle chunk of code whose purpose is > > not clear. It was originally introduced when we didn't have > > byte-compiled function objects, so its main purpose was one of > > performance, to avoid pessimizing the code by replacing trivial functio= n > > calls with more costly (byte-code "...") expressions but nowadays such > > (byte-code "...") expressions only occur basically at the top-level of > > .elc files where such pessimization would be unnoticeable in terms > > of performance. > > I agree completely, for what it's worth. > > > It does impact the readability of .elc files, OTOH, so I'm not > > completely happy with the result when considering the few cases where > > I was happy to be able to make sense of a .elc file to better understan= d > > the source of a problem (after all, that's why I wrote the > > elisp-byte-code-mode). > > I can speak only for myself, but I think the byte-compiler "magically" > deciding to turn (rare) top-level non-defuns into plain code rather > than byte code is confusing. It's much better with your patches. > > > > It seems the special case is necessary to avoid compilation errors, > > > > I haven't found it to be really necessary, no. > > Well, you fixed it with the second patch. > > > > and that it's used for (byte-compile 3), so I think the comment could > > > be improved a little. > > > > (byte-compile 3) seems to work correctly here even without the > > special case. It returns (byte-code "\300\207" [3] 1) which is indeed > > a correct expression that evaluates to 3 (just like the argument to > > `byte-compile` was an expression whose evaluation returns 3). > > No argument here. The case branch affects what happens when > (byte-compile 3) is called, but isn't necessary for the result to be > correct, and the comment can be misread to imply it's irrelevant in > this case. > > > Let's not forget that what `byte-compile` tries to do is to preserve th= e > > invariant that > > > > (eval EXP) =E2=89=83 (eval (byte-compile EXP)) > > I think byte-compile does different things for different arguments: > the behavior for symbols and other expressions is simply different. > > > This said, if you remove the special case, you will bump into > > a corner-case bug in `byte-compile` which happens because that function > > incorrectly considers that `byte-compile-top-level` returns a value > > whereas in reality it returns an expression (just like `byte-compile`): > > the decompilation happens to turn expressions that return constant > > values (like byte-compiled functions) into their value (as an > > optimization which relies on the fact that those objects are > > self-evaluating), so if you remove it, you then bump into this bug of > > byte-compile. The patch below would fix this bug. > > I don't think that was a bug, but it was an unfortunate wrinkle in the > (undocumented) API of byte-compile-top-level. > > > But indeed the decompilation of constants is handy since that's what > > people expect from `byte-compile`. When I (byte-compile '(lambda (x) > > (foo))) I expect to receive a byte-compiled function, and not > > a byte-code expression which when evaluated will return that > > byte-compiled function. > > I think it's more than handy: it's how I'd read the current > documentation, and how I'd expect a function called byte-compile to > behave. > > > > I'm not sure this case can actually happen without doing something > > > silly, but (byte-compile '(internal-get-closed-var 0)) throws an erro= r > > > with Stefan's patch, because the byte code is (byte-constant . 0) > > > (byte-return). > > > > This source code is arguably invalid, so it's not a real problem, but > > The source code is invalid, but the LAP code is valid-looking, and I > can't conclude it cannot be generated by valid source code being > passed to `byte-compile' somehow. > > > diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el > > index f46cab2c17..ae17553d0c 100644 > > --- a/lisp/emacs-lisp/bytecomp.el > > +++ b/lisp/emacs-lisp/bytecomp.el > > @@ -2674,7 +2674,11 @@ byte-compile > > (setq fun (byte-compile-top-level fun nil 'eval))) > > (if macro (push 'macro fun)) > > (if (symbolp form) > > - (fset form fun) > > + ;; byte-compile returns an *expression* equivalent to the > > I think this would be clearer if it read "byte-compile-top-level > returns an *expression*..." From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 27 17:30:14 2019 Received: (at 34757-done) by debbugs.gnu.org; 27 Jul 2019 21:30:14 +0000 Received: from localhost ([127.0.0.1]:45499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hrUGb-0007mu-MG for submit@debbugs.gnu.org; Sat, 27 Jul 2019 17:30:13 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33033) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hrUGa-0007lm-JN for 34757-done@debbugs.gnu.org; Sat, 27 Jul 2019 17:30:13 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1F6A885ADA; Sat, 27 Jul 2019 17:30:07 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 600238107A; Sat, 27 Jul 2019 17:30:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1564263005; bh=R+g2tPYo0mjOEs1F9C1lTXXX2LBhpAoiVbuCfqNmbIk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=oJtnPTCXe/rkqOmmE/zwfdG9uvsb2K2AUSzHNKJHAG+Cgd9/4HKrbxwWzUkHzhypm GiDUzdYu3EywLxD6fYN6JdYT/iqcys/epkXJ/McE/BnOA+W8wP5yM1bGSLSYq+ey2Z z1/h8cOhry+aR7Dtj26ZAuDifz7IHJVJoIo4BK8tRx40O/zrFKYqdqLWgQeAbyAmpj kul6RVn0jQkDFC/o4+oACZEi149zNyFeeOgWyLOwxQWXyOkGj9zjx5rDrSSmEUsoaS YXLjRYH1/wjTSfyqfKpM+n8RxGQCEYP0NWn04hG1E/uU+S73nTzuEThZJlh9H+Sr3S mZZkYiF9SXhHQ== Received: from alfajor (unknown [132.205.230.15]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 40FD4120236; Sat, 27 Jul 2019 17:30:05 -0400 (EDT) From: Stefan Monnier To: Pip Cet Subject: Re: bug#34757: Invalid bytecode from byte compiler Message-ID: References: Date: Sat, 27 Jul 2019 17:30:03 -0400 In-Reply-To: (Pip Cet's message of "Fri, 8 Mar 2019 21:13:37 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.000 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34757-done Cc: 34757-done@debbugs.gnu.org, chuntaro X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > We could fix byte-compile-out-toplevel to properly analyze how many > stack arguments the call takes, but this patch simply treats forms > like this as nontrivial: > > diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el > index 0b8f8824b4c..4e54e08ce14 100644 > --- a/lisp/emacs-lisp/bytecomp.el > +++ b/lisp/emacs-lisp/bytecomp.el > @@ -3025,6 +3025,7 @@ byte-compile-out-toplevel > (or (null (cdr rest)) > (and (memq output-type '(file progn t)) > (cdr (cdr rest)) > + (eql (length body) (cdr (car rest))) > (eq (car (nth 1 rest)) 'byte-discard) > (progn (setq rest (cdr rest)) t)))) > (setq maycall nil) ; Only allow one real function call. I installed this fix for now. Stefan From unknown Tue Jun 17 20:19:58 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 25 Aug 2019 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator