sammccall added a comment.
Agree there are readability concerns here (long macro names, out-of-line kinds,
complicated macros).
My suggestion would be to treat RefKind as an optional feature. Most tests
would just assert the set of marked locations and test the cases where kind is
interesting separately.
string markReferences(string TargetCode, string ReferencingCode, bool
WithKind);
// markReferences("int x;", "int y = ^x;", false) => "int ^x;"
// markReferences("int x;", "int y = ^x;", true) => "int $explicit^x;"
#define EXPECT_REFS(T, R) EXPECT_EQ(T, markReferences(Annotations(T).code(),
R, false)) << R;
#define EXPECT_TYPED_REFS(T, R) EXPECT_EQ(T,
markReferences(Annotations(T).code(), R, true)) << R;
================
Comment at: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp:248
// decls.
- testWalk(R"cpp(
+ EXPECT_EXPLICIT_REFERENCES(R"cpp(
template <typename> struct S {};
----------------
It's probably OK to use raw-strings inside macros these days...
Some versions of GCC had a problem with it, but the c++17 bump may have taken
care of those.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D137252/new/
https://reviews.llvm.org/D137252
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
