================
@@ -5858,6 +5858,26 @@ TEST_F(FormatTest, RespectWhitespaceInMacroDefinitions) {
verifyFormat("#define false((foo)0)", Style);
}
+TEST_F(FormatTest, CompoundLiteralInMacroDefinition) {
+ // https://github.com/llvm/llvm-project/issues/173583
+ //
+ // A C compound literal `(type){...}` is not a function/block. When used in a
+ // macro definition, clang-format should not treat `&` as a function name and
+ // reformat it as if it were `&(type) { ... }`.
+ FormatStyle Style = getLLVMStyle();
+ Style.Language = FormatStyle::LK_Cpp;
+ Style.IndentWidth = 4;
+ Style.TabWidth = 4;
+ Style.UseTab = FormatStyle::UT_Never;
+ Style.AlignEscapedNewlines = FormatStyle::ENAS_LeftWithLastLine;
+ Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_Empty;
+ Style.BreakBeforeBraces = FormatStyle::BS_Attach;
+
+ verifyNoChange("#define getAddr(v, type) &(type){v}", Style);
----------------
Lane0218 wrote:
Thanks for the review!
- I switched the regression to use `verifyFormat(...)` (instead of
`verifyNoChange`) since it’s the more common pattern here and should check the
same behavior (including the “messed up” input path).
- Since no special style options are required to reproduce this issue, I
dropped the explicit `getLLVMStyle()` / style overrides and rely on the default
style for the test.
- I also removed the `getAddr2` macro case (`int &(type){v;}`), as it doesn’t
form a valid/meaningful C/C++ snippet once expanded and makes the expected
formatting ambiguous.
Tests: FormatTests
https://github.com/llvm/llvm-project/pull/173771
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
