On Thu, 2015-10-29 at 11:38 -0600, Jeff Law wrote: > On 10/29/2015 10:49 AM, David Malcolm wrote: > > Our documentation describes -Wall as enabling "all the warnings about > > constructions that some users consider questionable, and that are easy to > > avoid > > (or modify to prevent the warning), even in conjunction with macros." > > > > I believe that -Wmisleading-indentation meets these criteria, and is > > likely to be of benefit to users who may not read release notes; it > > warns for indentation that's misleading, but not for indentation > > that's merely bad: the former are places where a user will likely > > want to fix the code. > > > > The fix is usually easy and obvious: fix the misleadingly-indented > > code. If that isn't an option for some reason, pragmas can be used to > > turn off the warning for a particular fragment of code: > > > > #pragma GCC diagnostic push > > #pragma GCC diagnostic ignored "-Wmisleading-indentation" > > if (flag) > > x = 3; > > y = 2; > > #pragma GCC diagnostic pop > > > > -Wmisleading-indentation has been tested with a variety of indentation > > styles (see gcc/testsuite/c-c++-common/Wmisleading-indentation.c) > > and on a variety of real-world projects. For example, in: > > https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg119790.html > > Patrick reports: > > "Tested by building the linux, git, vim, sqlite and gdb-binutils sources > > with -Wmisleading-indentation." > > > > With the tweak earlier in this kit I believe we now have a good > > enough signal:noise ratio for this warning to be widely used; hence this > > patch adds the warning to -Wall. > > > > Bootstrapped®rtested with x86_64-pc-linux-gnu. > > > > OK for trunk? > > > > gcc/c-family/ChangeLog: > > * c.opt (Wmisleading-indentation): Add to -Wall for C and C++. > > > > gcc/ChangeLog: > > * doc/invoke.texi (-Wall): Add -Wmisleading-indentation to the > > list. > > (-Wmisleading-indentation): Update documentation to reflect > > being enabled by -Wall in C/C++. > I'm sure we'll get some grief for this :-) > > Approved once we're clean in GCC. I'm going to explicitly say that > we'll have to watch for fallout, particularly as we start getting > feedback from Debian & Fedora mass-rebuilds as we approach release time. > If the fallout is too bad, we'll have to reconsider.
I believe we're now clean; I've committed this to trunk (*without* the blank-lines heuristic/levels idea) as r231539, having bootstrapped®rtested on x86_64-pc-linux-gnu (I've also successfully performed an all-configs build with it, although that was a while back now). > I'll pre-approve patches which fix anything caught by this option in GCC > as long as the fix just adjusts whitespace :-) > > jeff > >
