From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Zhiwei Chen Newsgroups: gmane.emacs.bugs Subject: bug#50331: [Anders Lindgren] Re: 28.0.50; Propose to obsolete cwarn.el Date: Fri, 03 Sep 2021 14:18:44 +0800 Message-ID: <877dfy5ghn.fsf@gmail.com> References: <87y28fa3qj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24183"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: 50331@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 03 08:19:11 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 1mM2Xf-000633-0o for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Sep 2021 08:19:11 +0200 Original-Received: from localhost ([::1]:49264 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mM2Xd-0004Je-J5 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Sep 2021 02:19:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38142) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mM2XW-0004JW-88 for bug-gnu-emacs@gnu.org; Fri, 03 Sep 2021 02:19:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59294) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mM2XW-00078F-0B for bug-gnu-emacs@gnu.org; Fri, 03 Sep 2021 02:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mM2XV-0006YT-SG for bug-gnu-emacs@gnu.org; Fri, 03 Sep 2021 02:19:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <87y28fa3qj.fsf@gmail.com> Resent-From: Zhiwei Chen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Sep 2021 06:19:01 +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 notabug Original-Received: via spool by 50331-submit@debbugs.gnu.org id=B50331.163064993725185 (code B ref 50331); Fri, 03 Sep 2021 06:19:01 +0000 Original-Received: (at 50331) by debbugs.gnu.org; 3 Sep 2021 06:18:57 +0000 Original-Received: from localhost ([127.0.0.1]:42607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mM2XQ-0006Y8-M5 for submit@debbugs.gnu.org; Fri, 03 Sep 2021 02:18:57 -0400 Original-Received: from mail-pj1-f46.google.com ([209.85.216.46]:45923) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mM2XP-0006Xs-3p for 50331@debbugs.gnu.org; Fri, 03 Sep 2021 02:18:56 -0400 Original-Received: by mail-pj1-f46.google.com with SMTP id f11-20020a17090aa78b00b0018e98a7cddaso3218646pjq.4 for <50331@debbugs.gnu.org>; Thu, 02 Sep 2021 23:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:date:message-id:user-agent:mime-version; bh=g6cSd3qZFOSq9e1qSiIDlVfvZIgV3ss3h2BDDefY3ds=; b=XWZ8RtZ0Ck6wyxPC0l0yefxrWb2r1X2rEuqTWJSe9cDGWH+HKLBvmnfsRjCfggOho4 E2+hoIWxhKTJRmc6xXeuIaGcr1xpBgS/XWfBYQg9GEMY6Zx1WwTy5GjQn2U7tr3eq3gO 23vDo9ys9qZdE7Y3MZks7tPw94zyBysTLUDQXxKBOhMwBqbfMMdOoujC7JIgsxZksomy H714S3MA2ZvTX+9cSxDHGwcBTdiRWQmhlgb4oTFWBV3GfyT5NA9ZSsOAYQ9jd/NF2aOW Rb8bclf/PEInFnFw37L7O6ZYaBeQ/bop3+q/Zd/13c+1vgtTRenYdYCqbpOOrxLUkYWC AFew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version; bh=g6cSd3qZFOSq9e1qSiIDlVfvZIgV3ss3h2BDDefY3ds=; b=t3lgZs/YfKoH1abiA185EkUkkApLPaXyP6seT85+Egg2OM8YF2hf4KsDm303fcak7/ RtXmxK/5PpMlesUpTFR92rjkZfNqgdRSLDpQFQx7Kigwrh5nWTGBb7jsRDZiC9/UjrCL 8rpITXgQckU7xJqbvv7rWBQVXO4c59D3P76kP1eNjIkwY9AuVwH9RpHN9WU/rqSmEHZN wvh1F9/5RSlIW6l+8lyBQ+ZY/04fo0o+EGxf1e4kBj1oBwkUU7IG+INKC5/JjwQWuKur 1tUT2O78YMPdkVqrc1MXXTfYxfUzFfhwc6MorLS/7ajaJZmHavmPXVCQK0psa+7eVH2E yXzQ== X-Gm-Message-State: AOAM532ZVnQgsePtUrWdBFIu2KH7Wiy+IbWMdGftVtrzI2tkfui+t/iM 6YBpmaC0IVqU6300vi9AojofZtAPC+VZYA== X-Google-Smtp-Source: ABdhPJwErhN+ozSvJjX5iPFlZSrSzJ4RBV7NCZcNecpyCCLGvQNUGzhetLU8ZHNwrySTix0uWeV2Tw== X-Received: by 2002:a17:90a:f695:: with SMTP id cl21mr2138095pjb.220.1630649928822; Thu, 02 Sep 2021 23:18:48 -0700 (PDT) Original-Received: from Youmu (192.69.92.236.16clouds.com. [192.69.92.236]) by smtp.gmail.com with ESMTPSA id y8sm4269971pfe.162.2021.09.02.23.18.46 for <50331@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Sep 2021 23:18:48 -0700 (PDT) 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:213315 Archived-At: --=-=-= Content-Type: text/plain -------------------- Start of forwarded message -------------------- From: Anders Lindgren Date: Thu, 2 Sep 2021 13:10:56 +0200 Subject: Re: 28.0.50; Propose to obsolete cwarn.el To: Zhiwei Chen Cc: bug-gnu-emacs@gnu.org --=-=-= Content-Type: multipart/alternative; boundary="==-=-=" --==-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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 > --==-=-= 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
--==-=-=-- --=-=-= Content-Type: text/plain -------------------- End of forwarded message -------------------- -- Zhiwei Chen --=-=-=--