llvm/llvm-project

Macros on access specifiers not formatted correctly

Open

#37,751 opened on Aug 1, 2018

View on GitHub
 (5 comments) (0 reactions) (1 assignee)C++ (10,782 forks)batch import
bugzillaclang-formatenhancementgood first issue

Repository metrics

Stars
 (26,378 stars)
PR merge metrics
 (Avg merge 1d 2h) (1,000 merged PRs in 30d)

Description

Bugzilla Link 38403
Version trunk
OS Windows NT

Extended Description

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?

Contributor guide