[clang-format] Top-level unwrapped lines don't follow a left brace

[owenpan]

Summary

This patch makes characterizing top-level unwrapped lines more precise. There are no test cases to add unless we want to include invalid ones, e.g.:

{
  int f(i)
  int i;
  {
    return i + 1;
  }
}

[HazardyKnusperkeks]

If there are no new tests, what went wrong before? Said invalid code?

[owenpan]

Yes, the said invalid code may get reformatted. However, the main purpose of this patch is to fix the efficiency issue as nested function declarators would no longer be checked for possible K&R C function definitions.

[MyDeveloperDay]

I guess this will prevent member functions in classes being treated as K&R functions right? if thats the case them this LGTM

[owenpan]

It will prevent them from even being checked in parseStructuralElement as IsTopLevel is now false:

case tok::l_paren: {
  parseParens();
  // Break the unwrapped line if a K&R C function definition has a parameter
  // declaration.
  if (!IsTopLevel || !Style.isCpp() || !Previous || FormatTok->is(tok::eof))
    break;
  const unsigned Position = Tokens->getPosition() + 1;
  assert(Position < AllTokens.size());
  if (isC78ParameterDecl(FormatTok, AllTokens[Position], Previous)) {
    addUnwrappedLine();
    return;
  }
  break;
}

clang/lib/Format/UnwrappedLineParser.cpp

do {
     case tok::l_square:
       if (Style.isCSharp()) {
         nextToken();
         parseCSharpAttribute();
         break;
       }
       LLVM_FALLTHROUGH;
     default:
-      parseStructuralElement(/*IsTopLevel=*/true);
+      parseStructuralElement(!HasOpeningBrace);
       break;
     }
   } while (!eof());
 }
 
 void UnwrappedLineParser::calculateBraceTypes(bool ExpectClassBody) {
   // We'll parse forward through the tokens until we hit
   // a closing brace or eof - note that getNextToken() will