[llvm-bugs] [Bug 38403] New: Macros on access specifiers not formatted correctly

[via llvm-bugs]

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

            Bug ID: 38403
           Summary: Macros on access specifiers not formatted correctly
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Formatter
          Assignee: unassignedclangbugs at nondot.org
          Reporter: steveire at gmail.com
                CC: djasper at google.com, klimek at google.com,
                    llvm-bugs at lists.llvm.org

Given this input:


    #define Q_SLOTS
    #define MY_ATTR

    class Foo {
    public:
      float b() { return b; }

    private Q_SLOTS:

      int a_ = 0;
      float b_ = 0;
    };

    class Foo {
    public:
      float b() { return b; }

    private MY_ATTR:

      int a_ = 0;
      float b_ = 0;
    };



clang format produces this result:


   
C:\dev\src\playground\cpp>C:\dev\src\llvm\build\releaseprefix\bin\clang-format.exe
cftest.cpp

    #define Q_SLOTS
    #define MY_ATTR

    class Foo {
    public:
      float b() { return b; }

    private Q_SLOTS:

      int a_ = 0;
      float b_ = 0;
    };

    class Foo {
    public:
      float b() { return b; }

    private
      MY_ATTR :

          int a_ = 0;
      float b_ = 0;
    };



That is - the MY_ATTR macro breaks subsequent formatting.

I notice 

void UnwrappedLineParser::parseAccessSpecifier() {
  nextToken();
  // Understand Qt's slots.
  if (FormatTok->isOneOf(Keywords.kw_slots, Keywords.kw_qslots))
    nextToken();
  // Otherwise, we don't know what it is, and we'd better keep the next token.
  if (FormatTok->Tok.is(tok::colon))
    nextToken();
  addUnwrappedLine();
}

so it seems Qt is handled as a special case? I assume there is some reason for
that instead of a generic solution. I'm not familiar enough with clang-format
internals to know.

Can the list of accepted tokens in access specifiers be extended as a user
customization point?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180801/e075ea9b/attachment.html>