[clang-format] Incorrectly formatted macro

[prj-]

$ cat foo.c 
#define foo(i, j)     (i - bar(j))
#define foo(i, j)     ((i) - bar(j))
$ clang-format --version
clang-format version 17.0.6
$ clang-format foo.c    
#define foo(i, j) (i - bar(j))
#define foo(i, j) ((i)-bar(j))
$ clang-format-18 --version
Debian clang-format version 18.0.0 (++20240119100743+cd05ade13a66-1~exp1~20240119220916.1830)
$ clang-format-18 foo.c 
#define foo(i, j) (i - bar(j))
#define foo(i, j) ((i)-bar(j))

Shouldn't the proper output be the following?

#define foo(i, j) (i - bar(j))
#define foo(i, j) ((i) - bar(j))

[rymiel]

It is being interpreted as a unary minus on the call (-bar(j)), being casted to i, due to ambiguities between types and variables in macros

AnnotatedTokens(L=1, P=0, T=5, C=0):
 M=0 C=0 T=Unknown S=1 F=0 B=0 BK=0 P=0 Name=l_paren L=1 PPK=2 FakeLParens= FakeRParens=0 II=0x0 Text='('
 M=0 C=1 T=Unknown S=0 F=0 B=0 BK=0 P=59 Name=l_paren L=2 PPK=2 FakeLParens= FakeRParens=0 II=0x0 Text='('
 M=0 C=1 T=Unknown S=0 F=0 B=0 BK=0 P=79 Name=identifier L=3 PPK=2 FakeLParens= FakeRParens=0 II=0x555bc6dc45a0 Text='i'
 M=0 C=0 T=CastRParen S=0 F=0 B=0 BK=0 P=63 Name=r_paren L=4 PPK=2 FakeLParens= FakeRParens=0 II=0x0 Text=')'
 M=0 C=0 T=UnaryOperator S=0 F=0 B=0 BK=0 P=140 Name=minus L=5 PPK=2 FakeLParens= FakeRParens=0 II=0x0 Text='-'
 M=0 C=0 T=Unknown S=0 F=0 B=0 BK=0 P=100 Name=identifier L=8 PPK=2 FakeLParens= FakeRParens=0 II=0x555bc6dc4600 Text='bar'
 M=0 C=0 T=Unknown S=0 F=0 B=0 BK=0 P=43 Name=l_paren L=9 PPK=2 FakeLParens= FakeRParens=0 II=0x0 Text='('
 M=0 C=1 T=Unknown S=0 F=0 B=0 BK=0 P=79 Name=identifier L=10 PPK=2 FakeLParens= FakeRParens=0 II=0x555bc6dc45d0 Text='j'
 M=0 C=0 T=Unknown S=0 F=0 B=0 BK=0 P=63 Name=r_paren L=11 PPK=2 FakeLParens= FakeRParens=0 II=0x0 Text=')'
 M=0 C=0 T=Unknown S=0 F=0 B=0 BK=0 P=43 Name=r_paren L=12 PPK=2 FakeLParens= FakeRParens=0 II=0x0 Text=')'

[prj-]

OK, I can bypass the issue with #define foo(i, j) (-bar(j)+(i)). If you don't think this is an issue and there is no way to resolve the ambiguity on your end, feel free to close the issue.

[prj-]

Could you please let me know, @rymiel?

[rymiel]

I think improvements can always be made, I'd keep it open for now, but I wouldn't expect it to be resolved any time soon

[prj-]

Wow, it got fixed earlier than I expected, thanks to you both!

[owenca]

/cherry-pick f826f55

[llvmbot]

/pull-request #80593

[tstellar]

PR has been created, we will track the status there.

[andreyv]

It looks like f826f55 caused a regression in macro formatting:

#define MAX ((uint32_t)-1)

now gets formatted as

#define MAX ((uint32_t) - 1)

while ClangFormat 17 leaves it as is. This commit was backported to stable releases, so 18.1.3 also exhibits the problem.

Both versions still correctly recognize

uint32_t max = (uint32_t)-1;

and don't change it.

[owenca]

This was fixed in 0baef3b.