llvm/llvm-project

Macros on access specifiers not formatted correctly

Open

#37.751 aperta il 1 ago 2018

Vedi su GitHub
 (5 commenti) (0 reazioni) (1 assegnatario)C++ (10.782 fork)batch import
bugzillaclang-formatenhancementgood first issue

Metriche repository

Star
 (26.378 star)
Metriche merge PR
 (Merge medio 1g 2h) (1000 PR mergiate in 30 g)

Descrizione

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?

Guida contributor