llvm/llvm-project

Macros on access specifiers not formatted correctly

Open

#37,751 建立於 2018年8月1日

在 GitHub 查看
 (5 留言) (0 反應) (1 負責人)C++ (10,782 fork)batch import
bugzillaclang-formatenhancementgood first issue

倉庫指標

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?

貢獻者指南