仓库指标
- Star
- (26,378 star)
- PR 合并指标
- (平均合并 1天 2小时) (30 天内合并 1,000 个 PR)
描述
| 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?