From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#50331: 28.0.50; Propose to obsolete cwarn.el Date: Thu, 2 Sep 2021 13:10:56 +0200 Message-ID: References: <87y28fa3qj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005159c105cb013d72" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39885"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50331@debbugs.gnu.org To: Zhiwei Chen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 02 13:24:32 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 1mLkpc-000AEZ-DK for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Sep 2021 13:24:32 +0200 Original-Received: from localhost ([::1]:41454 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLkpb-0006iZ-AH for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Sep 2021 07:24:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45046) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLkdW-0004b5-Oh for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 07:12:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56603) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mLkdW-0000Ue-He for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 07:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mLkdW-0005L4-3G for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 07:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Sep 2021 11:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50331 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.163058107620452 (code B ref -1); Thu, 02 Sep 2021 11:12:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 2 Sep 2021 11:11:16 +0000 Original-Received: from localhost ([127.0.0.1]:39916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mLkcl-0005Jo-Rh for submit@debbugs.gnu.org; Thu, 02 Sep 2021 07:11:16 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:43560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mLkcj-0005Je-Vz for submit@debbugs.gnu.org; Thu, 02 Sep 2021 07:11:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44966) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLkcj-00034A-DK for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 07:11:13 -0400 Original-Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]:41921) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mLkcg-0000N0-6j for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 07:11:13 -0400 Original-Received: by mail-lj1-x22b.google.com with SMTP id m4so2791324ljq.8 for ; Thu, 02 Sep 2021 04:11:08 -0700 (PDT) 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=Lis98+3PID/lr4qixKoflZpT6pFTuV6wsCOi3hPZ/cs=; b=XK49u0Z8pVrnABKH/4vHJumP1xSLoKO40pTFYqZWzaFktOy22YFY9dasuOl155Teos OqqKhPeSSpAaQfsJu0QvpwuAE9cx8OmZ5KhSTLnWzvzCdlzFMnKPCWiFF49LH1H+NeOr 1a8XZVkhbhrQAbq+gybETFCKze6ib7489To2AjZClz54pkwXNWf3TWc2+jHZ1D+zQyRu ejWealZ/VSKXyjUhht9pSsBQra2cTYRSkvUdR2xxOZyZ994HiDJdPQT25f+S2h9huw0/ SipdzeWk9cckwxYVQKSRnUS6wJFUBmXl7dU4tTtONHt26+nALcX1Y/jgqBCB7EXbKhcx Otyg== 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=Lis98+3PID/lr4qixKoflZpT6pFTuV6wsCOi3hPZ/cs=; b=Y+3LwBOtNQH2gmOw9tpTkJAn6FR6csdn8U2EUBIm8Nv8QBIT+JQHM8gEzedSHzPhqN DK06MkBlrbZExD3HsaCgBYArHbQk4GRyVX5tJe/fLSWAEMGsj0RrDy3ygZFdVdEBkbNa fglt6Iff7WQyYCMR3hPxpG321JDejG64tgMcp5I90T0d72c1fk6Gx9r4xSQQcHky4c7l KJGrH2gZfgx233okVmat4+xPgDSZLKmx1ihHe4/IkxoM0vTxocqO+bZYC+wrwDy1IFtz BYB4GSckuGcYASnvOcuMN/8SApRv5U+HSxJd7Mz8P1ouDQVRzBFFRKqPxh9DSYEbkcvx KK5Q== X-Gm-Message-State: AOAM530MTjrsS0sxDS/L7a9UOuelGqz/HTTP2NOQEK4RxZruuSPrpRDW yQ1bYKeHK5+01V1kJd5kYlx3JJDz1ZLK38XJVY1Cv0kb X-Google-Smtp-Source: ABdhPJwzhPg7CAK6BwpfzK95QKsLUeW2ky2+kmLluAXARRuTwVWWFhSrdNVx2fvAc7fsxQCo+VdjANXGMSM6hv8tjUs= X-Received: by 2002:a05:651c:2109:: with SMTP id a9mr2032421ljq.174.1630581067698; Thu, 02 Sep 2021 04:11:07 -0700 (PDT) In-Reply-To: <87y28fa3qj.fsf@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::22b; envelope-from=andlind@gmail.com; helo=mail-lj1-x22b.google.com 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:213265 Archived-At: --0000000000005159c105cb013d72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! I strongly object to deprecating CWarn! I can agree that highlighting reference parameters might not make much sense today. However, highlighting trailing semicolons and assignments inside expressions are things that often make code easier to read and understand, and it prevents you from writing broken code. In the assignment case, you only get warnings for trivial cases like "if (x =3D 0)". However, in more complex cases, where you have an intentional assignment deep inside an expression, the compiler doesn't (and shouldn't) issue an error or warning. However, having the operator highlighted makes a world of difference. For example: if ( x->SomeTest() && p =3D x->ThisMightPointToSomething() // By highlighting the "=3D", this code is easier to read. && score +=3D p->Score()) // Another one, which is hard to miss. { .. } Again, trailing semicolons, especially for "for", is a valid code pattern and few compilers I know of would issue a warning for it. In your example, gcc only issues a warning if the next line is indented. Highlighting the semicolon, on the other hand, still makes sense to me. Instead of deprecating CWarn, why don't we try to modernize it? If I had written the package today (rather than in 1999) I would have defined a new face that would inherit from font-lock-warning-face. By doing it that way, the new face would work in all color themes, at the same time a user can redefine it if there is a need for it. There was a poll that was posted to the Emacs community a couple of years ago about minor modes that should be enabled by default. If I remember correctly, CWarn mode was very high in that list (it might even have topped it). Unfortunately I no longer remember where the poll took place. -- Anders Lindgren On Thu, Sep 2, 2021 at 8:30 AM Zhiwei Chen wrote: > > Today, modern compilers can recognize the three cases described in cwarn > file. > > # semicolon after if/for/while > > if (value); > foo(); > > g++ -Wall produces helpful diagnostic information: > > a.cpp:11:5: note: ...this statement, but the latter is misleadingly > indented as if it were guarded by the =E2=80=98if=E2=80=99 > 11 | foo(); > | ^~~ > > > # assignment in expression > > if (x =3D 0) > foo(); > > a.cpp:10:9: warning: suggest parentheses around assignment used as truth > value [-Wparentheses] > 10 | if (x =3D 0); > | ~~^~~ > > g++ -Wall does a great job. > > > # reference parameter uses > > int bar(int& a) { > return a; > } > > I don't think it should be displayed in warning face, it's widely used > today. > > # conclusion > > Since the first two cases are not existent, and the last one is false > positive (IMO), I propose to obsolete cwarn. > > CCed Anders Lindgren, the author of cwarn. > > -- > Zhiwei Chen > --0000000000005159c105cb013d72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

I strongly=C2=A0object to deprecati= ng CWarn!

I can agree that highlighting reference= =C2=A0parameters might not make much=C2=A0sense=C2=A0today.

<= /div>
However, highlighting trailing semicolons and assignments inside = expressions are things that often make code easier to read and understand, = and it prevents you from writing broken code.

In t= he assignment=C2=A0case, you only get warnings for trivial cases like "= ;if (x =3D 0)". However, in more complex cases, where you have an inte= ntional assignment deep inside=C2=A0an expression, the compiler doesn't= (and shouldn't) issue an error or warning. However, having the operato= r highlighted makes a world of=C2=A0difference.

Fo= r example:

=C2=A0 =C2=A0 if (=C2=A0 =C2=A0x->So= meTest()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 && p =3D x->ThisM= ightPointToSomething()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // By highlighting= the "=3D", this code is easier to read.
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 && score +=3D p->Score())=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 =C2=A0 =C2=A0// Another one, which is hard to miss.
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 ..
=C2=A0 =C2=A0 = }

Again, trailing semicolons, especially=C2=A0for = "for", is a valid code pattern and few compilers I know of would = issue a warning for it. In your example, gcc only issues a warning if the n= ext line is indented. Highlighting the semicolon, on the other hand, still = makes sense to me.

Instead of deprecating CWarn, w= hy don't we try to modernize it? If I had written the package today (ra= ther than in 1999) I would have defined=C2=A0a new face that would inherit = from font-lock-warning-face. By doing it that way, the new face would work = in all color themes, at the same time a user can redefine it if there is a = need for it.

There was a poll that was posted to t= he Emacs community a couple of years ago about minor modes that should be e= nabled by default. If I remember correctly, CWarn mode was very high in tha= t list (it might even have topped it). Unfortunately I no longer remember w= here the poll took place.

=C2=A0 =C2=A0 -- Anders = Lindgren


On Thu, Sep 2, 2021 at 8:30 AM = Zhiwei Chen <condy0919@gmail.com<= /a>> wrote:
<= br> Today, modern compilers can recognize the three cases described in cwarn fi= le.

# semicolon after if/for/while

if (value);
=C2=A0 foo();

g++ -Wall produces helpful diagnostic information:

a.cpp:11:5: note: ...this statement, but the latter is misleadingly indente= d as if it were guarded by the =E2=80=98if=E2=80=99
=C2=A0 =C2=A011 |=C2=A0 =C2=A0 =C2=A0foo();
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0^~~


# assignment in expression

if (x =3D 0)
=C2=A0 foo();

a.cpp:10:9: warning: suggest parentheses around assignment used as truth va= lue [-Wparentheses]
=C2=A0 =C2=A010 |=C2=A0 =C2=A0if (x =3D 0);
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0~~^~~

g++ -Wall does a great job.


# reference parameter uses

int bar(int& a) {
=C2=A0 return a;
}

I don't think it should be displayed in warning face, it's widely u= sed today.

# conclusion

Since the first two cases are not existent, and the last one is false
positive (IMO), I propose to obsolete cwarn.

CCed Anders Lindgren, the author of cwarn.

--
Zhiwei Chen
--0000000000005159c105cb013d72--