From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99704 invoked by alias); 18 Jun 2015 17:10:54 -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 99689 invoked by uid 89); 18 Jun 2015 17:10:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-ob0-f180.google.com Received: from mail-ob0-f180.google.com (HELO mail-ob0-f180.google.com) (209.85.214.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 18 Jun 2015 17:10:51 +0000 Received: by obbgp2 with SMTP id gp2so58365056obb.2 for ; Thu, 18 Jun 2015 10:10:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hvjZgkxxwkl9Sx+2rccE3WIaofNCxK/dUqda7X6Tl4Q=; b=C6L4ce9fxPyTaVD0+xRaKzxBk6tsDzMKx7UWNVWlqTfZMpe2XFN4uKCztFMtNAwSzE 6sKdNW07ZNocQh4J/I44ttbfj/SJQ0Ia3D5h3A3/CRV4lfJ9M9xwvfUiJQOW4e9IPnKx ftN757Jm/un9zsy5/ebJAClxRzdgW8LV0OsfBsjq9jNJ73f/16aFlXHGueI29MKaRp9l NR2+daEqWkkbjmfxshBnTXB9j5ks/U5DJ1H+L/73FGmqF4ANKQ/x5BHlJb+/2atM+XTv Y9QhplYPfKhkmwxn+ytoKmCOzv0j6pkfSKd2P/HxmxVtfUUqPO/2oOv8dZ2qoF5I0PxY A02A== X-Gm-Message-State: ALoCoQm5BRDmfmmvLy7oi/7nUkmizFPc/RLK8gSHXSGdrTBMKe9+qYebPucmeoPNB/TzNt3J00Op X-Received: by 10.182.102.129 with SMTP id fo1mr10076010obb.24.1434647450027; Thu, 18 Jun 2015 10:10:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.96.167 with HTTP; Thu, 18 Jun 2015 10:10:29 -0700 (PDT) In-Reply-To: References: <1433871067-30661-1-git-send-email-patrick@parcs.ath.cx> <1433871067-30661-3-git-send-email-patrick@parcs.ath.cx> <1434645111.14663.146.camel@surprise> From: Patrick Palka Date: Thu, 18 Jun 2015 17:15:00 -0000 Message-ID: Subject: Re: [PATCH 3/3] Improve -Wmissing-indentation heuristics To: David Malcolm Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-06/txt/msg01294.txt.bz2 On Thu, Jun 18, 2015 at 12:57 PM, Patrick Palka wrote: > On Thu, Jun 18, 2015 at 12:31 PM, David Malcolm wrote: >> On Tue, 2015-06-09 at 13:31 -0400, Patrick Palka wrote: >>> This patch improves the heuristics of the warning in a number of ways. >>> The improvements are hopefully adequately documented in the code >>> comments. >>> >>> The additions to the test case also highlight the improvements. >>> >>> I tested an earlier version of this patch on more than a dozen C code >>> bases. I only found one class of bogus warnings yet emitted, in the >>> libpng and bdwgc projects. These projects have a coding style which >>> indents code inside #ifdefs as if this code was guarded by an if(), e.g. >>> >>> if (foo != 0) >>> x = 10; >>> else // GUARD >>> y = 100; // BODY >>> >>> #ifdef BAR >>> blah (); // NEXT >>> #endif >> >> We have detect_preprocessor_logic which suppresses warnings when there's >> preprocessor logic between BODY_EXPLOC and NEXT_STMT_EXPLOC, for cases >> like this: >> >> if (flagA) >> foo (); >> ^ BODY_EXPLOC >> #if SOME_CONDITION_THAT_DOES_NOT_HOLD >> if (flagB) >> #endif >> bar (); >> ^ NEXT_STMT_EXPLOC >> >> This currently requires that it be multiline preprocessor logic: there >> must be 3 or more lines between BODY_EXPLOC and NEXT_STMT_EXPLOC for >> this rejection heuristic to fire. > > Oh I now see why it requires 3 or more lines: one line each for the > #if, #endif and for the > >> >> Perhaps we could tweak or reuse that heuristic, perhaps if there's an >> entirely blank (or all whitespace) line separating them (given that this >> warning is all about the "look" of the code). > > That makes sense. What about just checking in > detect_preprocessor_logic() if there is > 1 line (instead of >= 3 > lines) between the body and the next statement? When that's the case, > then whatever is in between the start of the body must either be more > of the body (if it's a multi-line compound statement) or whitespace. > In either case we should not warn if the next statement is aligned > with the body. Actually, the body cannot be a compound statement because (with this patch) we have already bailed out in that case. So if there is > 1 line between the body and the next statement then there must be whitespace... unless there are just more #ifdefs, e.g. if (foo) bar (); #ifdef A #ifdef B baz (); #endif #endif We would want to warn here even though there are 2 lines, not 1 line, in between the body and the next statement. So we still have to directly check for a whitespace line, I think. > Yet we will still rightfully warn on the following > code: > > if (foo) // GUARD > bar (); // BODY > #ifdef BAZ > baz (); // NEXT > #endif > > because there is just one line between the body and the next > statement. The user can add a line between the body and the next > statement to suppress the warning if it's bogus. I meant to say, a (empty) line between the body and the #ifdef. > >> >>> These bogus warnings are pre-existing, however (i.e. not caused by this >>> patch). >> >> (nods) Fixing the false positives from libpng/bdwgc sounds like a >> separate issue and thus a separate patch then. >> >> [...snip...] >> >>