[llvm] r304083 - Added braces to address gcc warning: suggest explicit braces to avoid ambiguous 'else' [-Wdangling-else]. NFC.

[Craig Topper via llvm-commits]

This is what I get out of the preprocessed source around there with clang
before this commit which looks like the suppression that was supposed to
prevent this warning is happening. Unless a newer version of gcc has
learned to see through this trick?

  for (auto *S : cl::getRegisteredSubcommands()) {
    if (*S)
      switch (0) case 0: default: if (const ::testing::AssertionResult
gtest_ar = (::testing::internal::
EqHelper<(sizeof(::testing::internal::IsNullLiteralHelper("sc1")) ==
1)>::Compare("\"sc1\"", "S->getName()", "sc1", S->getName()))) ; else
::testing::internal::AssertHelper(::testing::TestPartResult::kNonFatalFailure,
"/Users/craig/Development/clang/llvm/unittests/Support/CommandLineTest.cpp",
532, gtest_ar.failure_message()) = ::testing::Message();
  }

~Craig

On Sat, May 27, 2017 at 10:39 PM, Davide Italiano <davide at freebsd.org>
wrote:

> On Sat, May 27, 2017 at 10:30 PM, Craig Topper <craig.topper at gmail.com>
> wrote:
> > EXPECT_STREQ should already be using this as far as I can tell.
> >
> > ~Craig
> >
>
> So, are you inclined to think this is a GCC false positive? If so, I'd
> like to understand what's the problem instead of blindly fixing
> warnings (and if we can't, well, maybe disable the warning entirely?)
>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170527/686b6188/attachment.html>