[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!