From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56672 invoked by alias); 9 Dec 2015 16:49:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 56662 invoked by uid 89); 9 Dec 2015 16:49:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 09 Dec 2015 16:49:54 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 50F5DC003314; Wed, 9 Dec 2015 16:49:53 +0000 (UTC) Received: from [10.3.236.204] (vpn-236-204.phx2.redhat.com [10.3.236.204]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB9GnqNS011170; Wed, 9 Dec 2015 11:49:52 -0500 Message-ID: <1449679792.1916.18.camel@surprise> Subject: Re: [PATCH] Add levels to -Wmisleading-indentation; add level 1 to -Wall From: David Malcolm To: Bernd Schmidt Cc: Jeff Law , Patrick Palka , Richard Biener , GCC Patches Date: Wed, 09 Dec 2015 16:49:00 -0000 In-Reply-To: <56684B84.6010906@redhat.com> References: <5637F4A5.1000405@redhat.com> <1449675493-43470-1-git-send-email-dmalcolm@redhat.com> <56684B84.6010906@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg01028.txt.bz2 On Wed, 2015-12-09 at 16:40 +0100, Bernd Schmidt wrote: > On 12/09/2015 04:38 PM, David Malcolm wrote: > > +/* The following function contains examples of bad indentation that's > > + arguably not misleading, due to a blank line between the guarded and the > > + non-guarded code. Some of the blank lines deliberately contain > > + redundant whitespace, to verify that this is handled. > > + Based on examples seen in gcc/fortran/io.c, gcc/function.c, and > > + gcc/regrename.c. > > + > > + At -Wmisleading-indentation (implying level 1) we shouldn't emit > > + warnings for this function. Compare with > > + fn_40_level_1 in Wmisleading-indentation-level-1.c and > > + fn_40_level_2 in Wmisleading-indentation-level-2.c. */ > > + > > +void > > +fn_40_implicit_level_1 (int arg) > > +{ > > +if (flagA) > > + foo (0); > > + > > + foo (1); > > + > > I personally see no use for the blank line heuristic, in fact I think it > is misguided. To my eyes a warning is clearly warranted for the examples > in this testcase. This goes back to the examples given in: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03225.html This is about managing the signal:noise ratio for something in -Wall. The distinction I want to make here is between badly indented code vs misleadingly indented code. Yes, the code is badly indented, but to my eyes the code is sufficiently badly indented that it has become *not* misleading: I can immediately see that something is awry. I want to preserve the -Wall level of the warning for the cases when it's not immediately clear that there's a problem. The levels idea means that you can turn off the blank-lines heuristic by setting -Wmisleading-indentation=2. > Do we actually have any users calling for this heuristic? FWIW, gcc trunk is clean with the blank-lines heuristic, but not without it (see the URL above for the 3 places I know of that fire without the heuristic). Dave