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?

贡献者指南