From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112880 invoked by alias); 3 Mar 2016 14:58:50 -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 112868 invoked by uid 89); 3 Mar 2016 14:58:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=353, 355, 348, rejects 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; Thu, 03 Mar 2016 14:58:47 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id B849E7F091 for ; Thu, 3 Mar 2016 14:58:46 +0000 (UTC) Received: from c64.redhat.com (vpn-230-159.phx2.redhat.com [10.3.230.159]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u23EwjJ5002960; Thu, 3 Mar 2016 09:58:46 -0500 From: David Malcolm To: gcc-patches@gcc.gnu.org Cc: David Malcolm Subject: [PATCH 1/2] PR c/68187: fix overzealous -Wmisleading-indentation (comment #0) Date: Thu, 03 Mar 2016 14:58:00 -0000 Message-Id: <1457018483-26829-1-git-send-email-dmalcolm@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00260.txt.bz2 PR c/68187 covers two cases involving poor indentation where the indentation is arguably not misleading, but for which -Wmisleading-indentation emits a warning. The two cases appear to be different in nature; one in comment #0 and the other in comment #1. Richi marked the bug as a whole as a P1 regression; it's not clear to me if he meant one or both of these cases, so the following two patches fix both. The rest of this post addresses the case in comment #0 of the PR; the followup post addresses the other case, in comment #1 of the PR. Building glibc (a9224562cbe9cfb0bd8d9e637a06141141f9e6e3) on x86_64 led to this diagnostic from -Wmisleading-indentation: ../stdlib/strtol_l.c: In function '____strtoul_l_internal': ../stdlib/strtol_l.c:356:9: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation] cnt < thousands_len; }) ^ ../stdlib/strtol_l.c:353:9: note: ...this 'for' clause, but it is not && ({ for (cnt = 0; cnt < thousands_len; ++cnt) ^ The code is question looks like this: 348 for (c = *end; c != L_('\0'); c = *++end) 349 if (((STRING_TYPE) c < L_('0') || (STRING_TYPE) c > L_('9')) 350 # ifdef USE_WIDE_CHAR 351 && (wchar_t) c != thousands 352 # else 353 && ({ for (cnt = 0; cnt < thousands_len; ++cnt) 354 if (thousands[cnt] != end[cnt]) 355 break; 356 cnt < thousands_len; }) 357 # endif 358 && (!ISALPHA (c) 359 || (int) (TOUPPER (c) - L_('A') + 10) >= base)) 360 break; Lines 354 and 355 are poorly indented, leading to the warning from -Wmisleading-indentation at line 356. The wording of the warning is clearly wrong: line 356 isn't indented as if guarded by line 353, it's more that lines 354 and 355 *aren't* indented. What's happening is that should_warn_for_misleading_indentation has a heuristic for handling "} else", such as: if (p) foo (1); } else // GUARD foo (2); // BODY foo (3); // NEXT and this heuristic uses the first non-whitespace character in the line containing GUARD as the column of interest: the "}" character. In this case we have: 353 && ({ for (cnt = 0; cnt < thousands_len; ++cnt) // GUARD 354 if (thousands[cnt] != end[cnt]) // BODY 355 break; 356 cnt < thousands_len; }) // NEXT and so it uses the column of the "&&", and treats it as if it were indented thus: 353 for (cnt = 0; cnt < thousands_len; ++cnt) // GUARD 354 if (thousands[cnt] != end[cnt]) // BODY 355 break; 356 cnt < thousands_len; }) // NEXT and thus issues a warning. As far as I can tell the heuristic in question only makes sense for "else" clauses, so the following patch updates it to only use the special column when handling "else" clauses, eliminating the overzealous warning. Doing so led to a nonsensical warning for libstdc++-v3/src/c++11/random.cc:random_device::_M_init: random.cc: In member function ‘void std::random_device::_M_init(const string&)’: random.cc:102:10: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] else if (token != "/dev/urandom" && token != "/dev/random") ^~ random.cc:107:5: note: ...this statement, but the latter is indented as if it does _M_file = static_cast(std::fopen(fname, "rb")); ^~~~~~~ so the patch addresses this by tweaking the heuristic that rejects aligned BODY and NEXT so that it doesn't require them to be aligned with the first non-whitespace of the GUARD, simply that they not be indented relative to it. Successfully bootstrapped®rtested on x86_64-pc-linux-gnu in combination with the following patch; standalone bootstrap®rtest is in progress. OK for trunk if the latter is successful? gcc/c-family/ChangeLog: PR c/68187 * c-indentation.c (should_warn_for_misleading_indentation): When suppressing warnings about cases where the guard and body are on the same column, only use the first non-whitespace column in place of the guard token column when dealing with "else" clauses. When rejecting aligned BODY and NEXT, loosen the requirement from equality with the first non-whitespace of guard to simply that they not be indented relative to it. gcc/testsuite/ChangeLog: PR c/68187 * c-c++-common/Wmisleading-indentation.c (fn_40_a): New test function. (fn_40_b): Likewise. (fn_41_a): Likewise. (fn_41_b): Likewise. --- gcc/c-family/c-indentation.c | 16 +++-- .../c-c++-common/Wmisleading-indentation.c | 79 ++++++++++++++++++++++ 2 files changed, 89 insertions(+), 6 deletions(-) diff --git a/gcc/c-family/c-indentation.c b/gcc/c-family/c-indentation.c index 521f992..c72192d 100644 --- a/gcc/c-family/c-indentation.c +++ b/gcc/c-family/c-indentation.c @@ -419,7 +419,8 @@ should_warn_for_misleading_indentation (const token_indent_info &guard_tinfo, { /* Don't warn if they are aligned on the same column as the guard itself (suggesting autogenerated code that doesn't - bother indenting at all). We consider the column of the first + bother indenting at all). + For "else" clauses, we consider the column of the first non-whitespace character on the guard line instead of the column of the actual guard token itself because it is more sensible. Consider: @@ -438,14 +439,17 @@ should_warn_for_misleading_indentation (const token_indent_info &guard_tinfo, foo (2); // BODY foo (3); // NEXT - If we just used the column of the guard token, we would warn on + If we just used the column of the "else" token, we would warn on the first example and not warn on the second. But we want the exact opposite to happen: to not warn on the first example (which is probably autogenerated) and to warn on the second (whose indentation is misleading). Using the column of the first non-whitespace character on the guard line makes that happen. */ - if (guard_line_first_nws == body_vis_column) + unsigned int guard_column = (guard_tinfo.keyword == RID_ELSE + ? guard_line_first_nws + : guard_vis_column); + if (guard_column == body_vis_column) return false; /* We may have something like: @@ -458,9 +462,9 @@ should_warn_for_misleading_indentation (const token_indent_info &guard_tinfo, foo (3); // NEXT in which case the columns are not aligned but the code is not - misleadingly indented. If the column of the body is less than - that of the guard line then don't warn. */ - if (body_vis_column < guard_line_first_nws) + misleadingly indented. If the column of the body isn't indented + more than the guard line then don't warn. */ + if (body_vis_column <= guard_line_first_nws) return false; /* Don't warn if there is multiline preprocessor logic between diff --git a/gcc/testsuite/c-c++-common/Wmisleading-indentation.c b/gcc/testsuite/c-c++-common/Wmisleading-indentation.c index 25db8fe..04500b7 100644 --- a/gcc/testsuite/c-c++-common/Wmisleading-indentation.c +++ b/gcc/testsuite/c-c++-common/Wmisleading-indentation.c @@ -903,3 +903,82 @@ void pr69122 (void) emit foo (1); } #undef emit + +/* In the following, the 'if' within the 'for' statement is not indented, + but arguably should be. + The for loop: + "for (cnt = 0; cnt < thousands_len; ++cnt)" + does not guard this conditional: + "cnt < thousands_len;". + and the poor indentation is not misleading. Verify that we do + not erroneously emit a warning about this. + Based on an example seen in glibc (PR c/68187). */ + +void +fn_40_a (const char *end, const char *thousands, int thousands_len) +{ + int cnt; + + while (flagA) + if (flagA + && ({ for (cnt = 0; cnt < thousands_len; ++cnt) + if (thousands[cnt] != end[cnt]) + break; + cnt < thousands_len; }) + && flagB) + break; +} + +/* As above, but with the indentation within the "for" loop fixed. + We should not emit a warning for this, either. */ + +void +fn_40_b (const char *end, const char *thousands, int thousands_len) +{ + int cnt; + + while (flagA) + if (flagA + && ({ for (cnt = 0; cnt < thousands_len; ++cnt) + if (thousands[cnt] != end[cnt]) + break; + cnt < thousands_len; }) + && flagB) + break; +} + +/* We should not warn for the following + (based on libstdc++-v3/src/c++11/random.cc:random_device::_M_init). */ + +void +fn_41_a (void) +{ + if (flagA) + { + } + else if (flagB) + fail: + foo (0); + + foo (1); + if (!flagC) + goto fail; +} + +/* Tweaked version of the above (with the label indented), which we should + also not warn for. */ + +void +fn_41_b (void) +{ + if (flagA) + { + } + else if (flagB) + fail: + foo (0); + + foo (1); + if (!flagC) + goto fail; +} -- 1.8.5.3