From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.help Subject: Re: How to avoid compiler warning `unused lexical variable' for `dolist' or `dotimes'? Date: Fri, 8 Jan 2021 15:03:22 +0100 Message-ID: <20210108140322.GD21347@tuxteam.de> References: <87o8hzj0hh.fsf@zoho.eu> <20210108110743.GB21347@tuxteam.de> <87pn2fhadb.fsf@zoho.eu> <877donh7xc.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k4f25fnPtRuIRUb3" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4485"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.5.21 (2010-09-15) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 08 15:30:06 2021 Return-path: Envelope-to: geh-help-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 1kxsmE-00014L-NR for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 08 Jan 2021 15:30:06 +0100 Original-Received: from localhost ([::1]:51542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxsmD-0008Ok-OH for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 08 Jan 2021 09:30:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58506) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxslf-0008Od-FY for help-gnu-emacs@gnu.org; Fri, 08 Jan 2021 09:29:31 -0500 Original-Received: from mail.tuxteam.de ([5.199.139.25]:43945) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1kxslY-0004NN-Sy for help-gnu-emacs@gnu.org; Fri, 08 Jan 2021 09:29:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:Date; bh=XeAIGQa9u6Tv7WCDlSJaNhNe0UOFedBFv4mvKXzBZwA=; b=Ij79vPqrGaOr0dHV39+HTFr6Fy8M5q+QVrL8aiLTKH0zcWDop41ySMHloTTkiRqR7JPS7F8gOZMNHXg0gA+OZ6LIvpbmHCNpJV1zdlD6ht7dNciRaA4l4yMCbVkMt6Lw/BnIMj7LovUDTBhlhMQk3uzlxGGx3zo/LCe5fcgQQ36n9IGDxJ49AYqB4Uzs3g4tAjVARdMoAVdOm7RgmkVo+6ebFEkqfvXIdco7SGXDlS5cB2XRsyn54XsiONjvBhAWiJFtsdyX8/YYwEzcrKW0wcoY2AsAeA/Cys/ay1HIjlMnqCWwR0IltK/b2ZRqQFdewAOiRNAIxh8BgW14oNrMfw==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1kxsMM-0001Qf-8n for help-gnu-emacs@gnu.org; Fri, 08 Jan 2021 15:03:22 +0100 Content-Disposition: inline In-Reply-To: <877donh7xc.fsf@zoho.eu> Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:127110 Archived-At: --k4f25fnPtRuIRUb3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 08, 2021 at 02:31:11PM +0100, Emanuel Berg via Users list for t= he GNU Emacs text editor wrote: > Philipp Stephani wrote: >=20 > >> No! Again, this is a problem with the byte compiler. > > > > Not really. The byte compiler can only compile what's > > macro-expanded >=20 > If the byte compiler because of its nature is incapable of > doing something, it shouldn't attempt or say anything... No. The byte compiler is doing exactly what it's been designed to: dependency analysis. And it making that "knowledge" it needs anyway available to the programmer via a warning. That is a Good Thing. And it is even right in its analysis: there /is/ an let-declared variable there which is unused. The macro expander put it there. I think Philipp and me managed to convince you of that? [...] > > (let ((i counter)) > > t)) > > > > As you can see, `i' is definitely unused in the second `let' > > form - the byte compiler is right. >=20 > Hm... what is the definition of being used in terms of > a variable? read/write? I think it's just access (i.e. read). But you could try for yourself (just cook up a RETURN expression where the count variable is set and compile that code. Perhaps better don't run it :) > Also, that is a stub, I don't remember what the OP did but he > did use it You mean he used the count variable? In the context of the RETURN expression? And then (s)he gets the warning? I'd be surprised. We'd be digging in the wrong place, then. > and I think this is what one thinks the byte > compiler is referring to with its warning rather than certain > parts of what is macro-expanded... Hm. Could you provide the original code snippet? Cheers - t --k4f25fnPtRuIRUb3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAl/4ZioACgkQBcgs9XrR2kY2awCePsVNDuMVKuvx0P7IvdJJz7n1 D0gAn3ft2SY8GBzAQQU0OGla+8+9ytb5 =8uEU -----END PGP SIGNATURE----- --k4f25fnPtRuIRUb3--