[clang-format] [PR45942] [[nodiscard]] causes && to be miss interpreted as BinaryOperators

[MyDeveloperDay]

Summary

https://bugs.llvm.org/show_bug.cgi?id=45942

With Chromium style (although that is not important) its just it defines PointerAligmment: Left

The following arguments S&& are formatted differently depending on if the class has an attribute between it and the class identifier

class S {
  S(S&&) = default;
};

class [[nodiscard]] S {
  S(S &&) = default;
};

The prescense of [[nodiscard]] between the class/struct and the { causes the { to be incorrectly seen as a TT_FunctionLBrace which in turn transforms all the && to be TT_BinaryOperators rather than TT_PointerOrReference, as binary operators other spacing rules come into play causing a miss format

This revision resolves this by allowing the parseRecord to consider the [[nodisscard]]

[MyDeveloperDay]

pre-merge tests showed I wasn't quite rebased however it overlaps with D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

However I feel I made a mistake with the previous fix because the l_square and r_square haven't always been assigned to be of type TT_AttributeSquare yet.

Update this patch so the test from both revision still work.

clang/lib/Format/UnwrappedLineParser.cpp

void UnwrappedLineParser::parseRecord(bool ParseAsExpr) {
   const FormatToken &InitialToken = *FormatTok;
   nextToken();
 
   // The actual identifier can be a nested name specifier, and in macros
   // it is often token-pasted.
   // An [[attribute]] can be before the identifier.
   while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::hashhash,
                             tok::kw___attribute, tok::kw___declspec,
-                            tok::kw_alignas, TT_AttributeSquare) ||
+                            tok::kw_alignas, tok::l_square, tok::r_square) ||
          ((Style.Language == FormatStyle::LK_Java ||
            Style.Language == FormatStyle::LK_JavaScript) &&
           FormatTok->isOneOf(tok::period, tok::comma))) {
     if (Style.Language == FormatStyle::LK_JavaScript &&
         FormatTok->isOneOf(Keywords.kw_extends, Keywords.kw_implements)) {
       // JavaScript/TypeScript supports inline object types in
       // extends/implements positions:
       //     class Foo implements {bar: number} { }

clang/unittests/Format/FormatTest.cpp

TEST_F(FormatTest, UnderstandsSquareAttributes) {
   FormatStyle MultiLineFunctions = getLLVMStyle();
   MultiLineFunctions.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
   verifyFormat("[[unused]] int b() {\n"
                "  return 42;\n"
                "}\n",
                MultiLineFunctions);
 }
 
+TEST_F(FormatTest, AttributeClass) {
+  FormatStyle Style = getChromiumStyle(FormatStyle::LK_Cpp);
+  verifyFormat("class S {\n"
+               "  S(S&&) = default;\n"
+               "};",
+               Style);
+  verifyFormat("class [[nodiscard]] S {\n"
+               "  S(S&&) = default;\n"
+               "};",
+               Style);
+  verifyFormat("class __attribute((maybeunused)) S {\n"
+               "  S(S&&) = default;\n"
+               "};",
+               Style);
+  verifyFormat("struct S {\n"
+               "  S(S&&) = default;\n"
+               "};",
+               Style);
+  verifyFormat("struct [[nodiscard]] S {\n"
+               "  S(S&&) = default;\n"
+               "};",
+               Style);
+}
+
 TEST_F(FormatTest, AttributePenaltyBreaking) {
   FormatStyle Style = getLLVMStyle();
   verifyFormat("void ABCDEFGH::ABCDEFGHIJKLMN(\n"
                "    [[maybe_unused]] const shared_ptr<ALongTypeName> &C d) {}",
                Style);
   verifyFormat("void ABCDEFGH::ABCDEFGHIJK(\n"
                "    [[maybe_unused]] const shared_ptr<ALongTypeName> &C d) {}",
                Style);