From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pierre Rouleau Newsgroups: gmane.emacs.bugs Subject: bug#49749: 26.3; 26.3 & 27.2: invalid byte compiler warning in short-circuited or form Date: Sat, 31 Jul 2021 09:59:02 -0400 Message-ID: References: <1B5C81C0-5D9A-4ED5-B56A-FC6AAA1A8A87@gmail.com> <8735rycvdr.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b5a70005c86bbd05" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6303"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 49749@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 31 16:04:12 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 1m9pb2-0001GN-0Q for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 31 Jul 2021 16:04:12 +0200 Original-Received: from localhost ([::1]:34140 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9pav-000391-PP for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 31 Jul 2021 10:04:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9pX0-0007sn-Lk for bug-gnu-emacs@gnu.org; Sat, 31 Jul 2021 10:00:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51202) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m9pX0-0001Wd-Cc for bug-gnu-emacs@gnu.org; Sat, 31 Jul 2021 10:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m9pX0-0007Lp-9L for bug-gnu-emacs@gnu.org; Sat, 31 Jul 2021 10:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pierre Rouleau Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 Jul 2021 14:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49749 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 49749-submit@debbugs.gnu.org id=B49749.162773996128176 (code B ref 49749); Sat, 31 Jul 2021 14:00:02 +0000 Original-Received: (at 49749) by debbugs.gnu.org; 31 Jul 2021 13:59:21 +0000 Original-Received: from localhost ([127.0.0.1]:34515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9pWL-0007KO-42 for submit@debbugs.gnu.org; Sat, 31 Jul 2021 09:59:21 -0400 Original-Received: from mail-ed1-f49.google.com ([209.85.208.49]:39769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9pWJ-0007KC-KD for 49749@debbugs.gnu.org; Sat, 31 Jul 2021 09:59:20 -0400 Original-Received: by mail-ed1-f49.google.com with SMTP id y12so17625851edo.6 for <49749@debbugs.gnu.org>; Sat, 31 Jul 2021 06:59:19 -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=QA9bkM5rDQUPEroG3iTFfFILZKOVImfqRMqWkZhF9Gc=; b=mPC99O7UknvNQkRNkHj+kmAuuVbqqAUB0u2V8YsGI2BiFB7wNVDFeHfxlkvG/NPtsa 8XgCVWcO3OzceAXzKRwA4CsP9P/LCzBEumtRGwoMLMMKpCBeHGFLdZ/S2m3/8micQbUD heQ1VIlwF09CdKKTp7OEIjmGJ4ym0exJDN3zvrkFVOwU+XVQoP6td0pQpdB/ztUErviR ZOoSGGiKfJIC+1n0UzZDMdkdMRsSJg3O9ZSdknGLXiNMCiC6EtAAqxg6yKL5RGw/XRu9 tWOAMIaZTwl3uiAUwKdt7ewgUQiMKXflIZt88yKDQtz8qBkivrs+jlQJ6yBjIOdn7frI j0ug== 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=QA9bkM5rDQUPEroG3iTFfFILZKOVImfqRMqWkZhF9Gc=; b=ITa8VOS/Nj6lXLLYngiuPg7sSKAoAEBmEdEYbyoKIjkda0YsaMeR7ia+/FHTOijPSv wYP1SSOqa4es88fBvBTJkgjwpYi7HYxH4zWpt1Kr6ZZ7tsZQLeDhH9co5SVIU6bNBaHA iq4Q7OacvNeCNRUJDW9da6KttJDLv20gSts666KV6JsIHP1CY58iUeDk3rHmdzXSlOPb 5dHU5xEgLcjXQY1FTbqiRmvKu1b+MkYxOsYTNdiwLTJt542I1SOnpxMQ2GsMt7hKbxqV 2//0uXrmla0babb+BNArmTJOfX42hOzW2B6ebJLuIFrEnOK+d1yK1iWKe03opUour4PT 1YUQ== X-Gm-Message-State: AOAM531F2r4BMHdnsIbo46qGh6FUfPKtgMyyfv+0QQ6kg2iHdUIsHCip 1pVwmYLg2OZB1GzDa5yYds1+B0iyfFhTWuQ/UI4= X-Google-Smtp-Source: ABdhPJyLsfxZCRDZiVgPiw3KDjYn6XoOqwnBFcPjo9LyoK3vNSNoUQiguR4Il0Ed3RM5G2cWkdJAHDQ9zHaAHT4AIBU= X-Received: by 2002:a05:6402:550:: with SMTP id i16mr9186020edx.177.1627739953406; Sat, 31 Jul 2021 06:59:13 -0700 (PDT) In-Reply-To: <8735rycvdr.fsf@gnus.org> 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:210985 Archived-At: --000000000000b5a70005c86bbd05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 28, 2021 at 11:26 AM Lars Ingebrigtsen wrote: > Pierre Rouleau writes: > > > (defun f-or () > > "Use or." > > (when (or (null (boundp 'foo)) > > (null foo)) ;=3D> ``Warning: reference to free variable > =E2=80=98foo=E2=80=99`` > > (message "foo is not set"))) > > The message about invalid stuff is only discarded if Emacs is trivially > able to deduce that it'll never be evaluated -- and as you've found out, > it's easy to make that heuristic not be heeded (see > `byte-compile-maybe-guarded' for details). > Thanks. I must admit I do not know the byte compiler code much at this point. > So I'm not sure this is a bug -- Emacs can't determine all cases where > we won't be executing the code in question at compile time. > Well, from the perspective of a user, that would look at the very least as a technical limitation. The byte compiler is able to report unused lexical variables. It's able to report access to unbound symbols in a large number of code patterns. That helps detect a lot of coding mistakes and that's very valuable. It may be difficult, or perhaps even not possible, to prevent the warning in the situation I reported. If the byte compiler cannot be improve to handle this situation, could this scenario be added to the list of know limitation= s of the byte-compiler? Maybe someday it will become possible to handle it and this scenario will help the process? --=20 /Pierre --000000000000b5a70005c86bbd05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 28, 2021 at 11:26 AM Lars= Ingebrigtsen <larsi@gnus.org> = wrote:
Pierre Ro= uleau <proule= au001@gmail.com> writes:

> (defun f-or ()
>=C2=A0 =C2=A0"Use or."
>=C2=A0 =C2=A0(when (or (null (boundp 'foo))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(null foo))=C2=A0 ;=3D&= gt; ``Warning: reference to free variable =E2=80=98foo=E2=80=99``=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0(message "foo is not set")))

The message about invalid stuff is only discarded if Emacs is trivially
able to deduce that it'll never be evaluated -- and as you've found= out,
it's easy to make that heuristic not be heeded (see
`byte-compile-maybe-guarded' for details).
=C2=A0<= /div>
Thanks.=C2=A0 I must admit I do not know the byte compiler code m= uch at this point.
=C2=A0
So I'm not sure this is a bug -- Emacs can't determine all cases wh= ere
we won't be executing the code in question at compile time.

Well, from the perspective of a user, that would l= ook at the
very least as a technical limitation.
<= br>
The byte compiler is able to report unused lexical variables.= =C2=A0
It's able to report access to unbound symbols in = a large
number of code patterns.=C2=A0 That helps detect a l= ot of coding mistakes
and that's very valuable.

It may be difficult, or perhaps even not possible, to preve= nt the warning
in the situation I reported.=C2=A0 If the byt= e compiler cannot be improve to handle
this situation, could thi= s scenario be added to the list of know limitations
of the byte-c= ompiler?=C2=A0 Maybe someday it will become possible to handle it
and this scenario will help the process?
=C2=A0

--
/Pierre
--000000000000b5a70005c86bbd05--