This is an archive of the discontinued LLVM Phabricator instance.

clang-format: Add Block{Begin,End}Macros option
ClosedPublic

Authored by poiru on Jun 30 2015, 8:33 AM.

Details

Summary

This adds the BlockBeginMacros and BlockEndMacros options that can be
used to make certain macros add indent levels similarly to '{' and '}',
respectively.

Mozilla code, for example, uses several macros that begin and end a scope.
Previously, Clang-Format removed the indentation resulting in:

MACRO_BEGIN(...)
MACRO_ENTRY(...)
MACRO_ENTRY(...)
MACRO_END

Now, using e.g. 'BlockBeginMacros: "^[A-Z_]+_BEGIN$"' and
'BlockEndMacros: "^[A-Z_]+_END$"', the result is as expected:

MACRO_BEGIN(...)

MACRO_ENTRY(...)
MACRO_ENTRY(...)

MACRO_END

Diff Detail

Repository
rL LLVM

Event Timeline

poiru updated this revision to Diff 28788.Jun 30 2015, 8:33 AM
poiru retitled this revision from to clang-format: Add Block{Begin,End}Macros option.
poiru updated this object.
poiru added a reviewer: djasper.
poiru added a subscriber: Unknown Object (MLST).

Heya, thanks for working on this. I think we'll want to make this a bit more generic - I'm not saying the first version needs all features, but we should think about how we want to put it into the config with the future in mind.

Specifically, we'll want to specify macros that:

  • open blocks
  • open declaration contexts (class) (MS' test framework uses those)
  • are full statements (currently we have heuristics for that, but those are limited)
djasper added inline comments.Jul 1 2015, 2:08 AM
include/clang/Format/Format.h
159 ↗(On Diff #28788)

I think this should be consistent with 'ForEachMacros' and whatever other macro kinds we are going to introduce (see Manuel's comment). Specifically, all of them should either be a regular expression or a list of strings. I am fine with turning them into regular expressions.

I wonder whether all of these would be more discoverable if we chose the name so that they are consecutive, e.g. MacrosBlockBegin, MacrosBlockEnd, MacrosForEach. But I am not sure. Any thoughts?

lib/Format/Format.cpp
460 ↗(On Diff #28788)

Can you set values for the new flags here, so it properly handles IPC_BEGIN_MESSAGE_MAP and IPC_END_MESSAGE_MAP?

477 ↗(On Diff #28788)

Do you have good defaults here?

1168–1180 ↗(On Diff #28788)

Can you wrap this entire if statement in an:

if (Style.Language == FormatStyle::LK_Cpp) {
}

?

This isn't relevant to other languages and matching every single identifier against a regular expression seems like a waste then.

lib/Format/UnwrappedLineParser.cpp
404 ↗(On Diff #28788)

I'd (very slightly) prefer to keep this assert at the top, i.e.:

assert(FormatTok->isOneOf(tok::l_brace, TT_MacroBlockBegin) && "...");
const bool MacroBlock = FormatTok->is(TT_MacroBlockBegin);
421–422 ↗(On Diff #28788)

Can you pull the "!" into the ternary expression? Otherwise this is just hard to read for me (can't really explain why).

poiru added inline comments.Jul 1 2015, 2:37 PM
include/clang/Format/Format.h
159 ↗(On Diff #28788)

I went with MacroBlock{Begin,End} because the plural at the beginning sounds weird. I'll add a regex-based MacroForEach in a future patch.

lib/Format/Format.cpp
477 ↗(On Diff #28788)

Yes, but I think we (Mozilla) would prefer to keep them in our .clang-format file because the set of macros is likely to change.

poiru updated this revision to Diff 28900.Jul 1 2015, 2:38 PM

Review comments addressed.

djasper accepted this revision.Jul 3 2015, 1:03 AM
djasper edited edge metadata.

Thanks. Very nice :-).

This revision is now accepted and ready to land.Jul 3 2015, 1:03 AM
This revision was automatically updated to reflect the committed changes.
thakis added a subscriber: thakis.Oct 10 2016, 11:50 AM

I noticed that using this slows down clang-format about 300% -- https://llvm.org/bugs/show_bug.cgi?id=30656