krasimir added a comment.
I think situations where we infer M(x) to expand to a "type" without
const/volatile close-by are too ambiguous an we will have the opposite problem:
formatting certain binary expressions as type pointer/references. Some sort of
a list of macros that clang-format assumes expand to a "type" could eliminate
ambiguities, but has its own problems.
I think the case where there's a const/volatile/typename/typedef etc. around
M(x) is very interesting; not sure if there are many practical ambiguities
there.
There was an idea of giving a bunch of #define-s to clang-format (maybe with a
small subset of what's possible) and use these rules to decide how to format
matching forms, but that's hard (requires some sort of "virtual expanded token
sequences" that the formatter should undestrand how to handle) to do and I
don't know what's the status of that.
================
Comment at: clang/unittests/Format/FormatTest.cpp:7360
+ verifyFormat("int f(M(x) *p1 = nullptr, M(x) *p2, volatile M(x) *p3);");
+ verifyFormat("M(x) *foo();");
+ verifyFormat("const M(x) *foo(M(x) *a = nullptr);");
----------------
This is ambiguous: the `*` could be a binary operator:
https://godbolt.org/z/n7Jr-h
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D75364/new/
https://reviews.llvm.org/D75364
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
