llvm/llvm-project
Voir sur GitHubMacros on access specifiers not formatted correctly
Open
#37 751 ouverte le 1 août 2018
bugzillaclang-formatenhancementgood first issue
Métriques du dépôt
- Stars
- (26 378 stars)
- Métriques de merge PR
- (Merge moyen 1j 2h) (1 000 PRs mergées en 30 j)
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?