From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#69108: false-positive warning "variable =?UTF-8?Q?=E2=80=98=5F=E2=80=99?= not left unused" in if-let* and if-let Date: Sat, 17 Feb 2024 10:04:11 +0200 Message-ID: <86eddbv7no.fsf@gnu.org> References: <87il2ryi30.fsf@web.de> <87mss09bnc.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="521"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 69108@debbugs.gnu.org, Hi-Angel@yandex.ru To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 17 09:05:06 2024 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 1rbFh3-000AP1-3L for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Feb 2024 09:05:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rbFgh-00049K-FP; Sat, 17 Feb 2024 03:04:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rbFgg-00049A-C5 for bug-gnu-emacs@gnu.org; Sat, 17 Feb 2024 03:04:42 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rbFgg-0003ZF-42 for bug-gnu-emacs@gnu.org; Sat, 17 Feb 2024 03:04:42 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rbFgz-0004x7-L5 for bug-gnu-emacs@gnu.org; Sat, 17 Feb 2024 03:05:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Feb 2024 08:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69108 X-GNU-PR-Package: emacs Original-Received: via spool by 69108-submit@debbugs.gnu.org id=B69108.170815708919012 (code B ref 69108); Sat, 17 Feb 2024 08:05:01 +0000 Original-Received: (at 69108) by debbugs.gnu.org; 17 Feb 2024 08:04:49 +0000 Original-Received: from localhost ([127.0.0.1]:60381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbFgm-0004wZ-Nq for submit@debbugs.gnu.org; Sat, 17 Feb 2024 03:04:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbFgh-0004wI-MZ for 69108@debbugs.gnu.org; Sat, 17 Feb 2024 03:04:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rbFgG-0003Wq-5m; Sat, 17 Feb 2024 03:04:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=UD78Zcv0aFTSjCO5sh0tu3KCpH2QeGSIAVQBU1cJICE=; b=ELYP/0SuCKUp55ToV+Pq NH6QMYRqwgqpBtrv10Q3KyxAv6Ct+Yh9rlnGs6TvyCONUD4PZ+ZiBgAcKwkWrV7Tq3A7GQXL7Ugk+ 8VCrbymz2CtWlOQXXNffICFqbVbQbEz4HwYqUblXA1xqjWTzhNNP+erKTTElGr67vVHiFs7aZKF1o 2kya1GbYqRBSZS8Z39x7Jz6MNQz/ku6ihKoJOut4Ude3foyF65kYZRMOry6eZWU5bqSIO9Np+6HI9 uueV4KYpxVnBXrzDQlbTeUUeyN/hYZp6Vhie3LaSw4lP6ul4ZqLUZaZVwYc6DnUtdu+xLvN0UmF8I ntKRgHmWbTmfDw==; In-Reply-To: <87mss09bnc.fsf@web.de> (bug-gnu-emacs@gnu.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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280115 Archived-At: > Cc: 69108@debbugs.gnu.org > Date: Sat, 17 Feb 2024 01:28:55 +0100 > From: Michael Heerdegen via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > --- a/lisp/subr.el > +++ b/lisp/subr.el > @@ -2575,12 +2575,12 @@ delay-mode-hooks > (defun internal--build-binding (binding prev-var) > "Check and build a single BINDING with PREV-VAR." > (setq binding > - (cond > - ((symbolp binding) > + (pcase binding > + ((pred symbolp) > (list binding binding)) > - ((null (cdr binding)) > - (list (make-symbol "s") (car binding))) > - (t binding))) > + ((or `(,test) `(_ ,test)) > + (list (make-symbol "s") test)) > + (_ binding))) Thanks, but can we please leave this as 'cond', instead of converting it to a 'pcase'? It doesn't seem to be justified here, and even less so since you need to rewrite all the existing conditions. > (defmacro if-let (spec then &rest else) > "Bind variables according to SPEC and evaluate THEN or ELSE. > -Evaluate each binding in turn, as in `let*', stopping if a > -binding value is nil. If all are non-nil return the value of > -THEN, otherwise the last form in ELSE. > +Evaluate each binding in turn, as in `let*', stopping if a binding value > +is nil. If all are non-nil return the value of THEN, otherwise the > +value of the last ELSE form or nil if there are none. > > Each element of SPEC is a list (SYMBOL VALUEFORM) that binds > SYMBOL to the value of VALUEFORM. An element can additionally be > @@ -2642,9 +2642,9 @@ if-let > interest. It can also be of the form SYMBOL, then the binding of > SYMBOL is checked for nil. > > -As a special case, interprets a SPEC of the form \(SYMBOL SOMETHING) > -like \((SYMBOL SOMETHING)). This exists for backward compatibility > -with an old syntax that accepted only one binding." > +As a special case that exists for backward compatibility only, a > +complete SPEC of the form \(SYMBOL SOMETHING) is interpreted like > +\((SYMBOL SOMETHING))." > (declare (indent 2) > (debug ([&or (symbolp form) ; must be first, Bug#48489 > (&rest [&or symbolp (symbolp form) (form)])] This hunk seems to be unrelated? And it is not necessarily for the better, IMO, at least not all of it (replaces active tense with passive, refills text that doesn't need refilling, and other minor issues, like the confusing use of construct state in "last ELSE form").