This is an archive of the discontinued LLVM Phabricator instance.

Leave alone the semicolon after the MacroBlockBegin name
AbandonedPublic

Authored by owenpan on Apr 4 2019, 11:21 PM.

Details

Summary

This patch fixes the bug below.

The code:

FOO_BEGIN();
  FOO_ENTRY
FOO_END();

is erroneously formatted to:

FOO_BEGIN()
  ;
  FOO_ENTRY
FOO_END();

Diff Detail

Repository
rC Clang

Event Timeline

owenpan created this revision.Apr 4 2019, 11:21 PM

The documentation examples of MacroBlockBegin are:

/// A regular expression matching macros that start a block.
/// \code
///    # With:
///    MacroBlockBegin: "^NS_MAP_BEGIN|\
///    NS_TABLE_HEAD$"
///    MacroBlockEnd: "^\
///    NS_MAP_END|\
///    NS_TABLE_.*_END$"
///
///    NS_MAP_BEGIN
///      foo();
///    NS_MAP_END
///
///    NS_TABLE_HEAD
///      bar();
///    NS_TABLE_FOO_END
///
///    # Without:
///    NS_MAP_BEGIN
///    foo();
///    NS_MAP_END
///
///    NS_TABLE_HEAD
///    bar();
///    NS_TABLE_FOO_END
/// \endcode

It doesn't appear that a semicolon after the macro is expected, so the semicolon is treated as an empty statement inside the block.

There are some reasonable arguments for this. semicolons go after statement-like things, block introducers are not statement-like in general. Even if the particular implementation requires a semicolon (e.g. glBegin()), it breaks abstraction to make the user type it, it should be part of the macro instead.

If this doesn't work for your codebase, can you share some details about the macro (what it's for and what it expands to) that motivates this change?

owenpan abandoned this revision.Apr 5 2019, 7:14 PM

The semicolon is redundant but makes the MacroBlockBegin name stand out more. Nonetheless, I agree it's not a bug and we should leave the current behavior as is.