aaron.ballman added inline comments.
================
Comment at: unittests/ASTMatchers/ASTMatchersTest.cpp:4283
@@ +4282,3 @@
+ EXPECT_TRUE(matches("void f(int i);", functionProtoType()));
+ EXPECT_TRUE(matches("void f();", functionProtoType(parameterCountIs(0))));
+ EXPECT_TRUE(notMatchesC("void f();", functionProtoType()));
----------------
> I don't understand what would be tested by adding a test for
> parameterCountIs() on a function that doesn't have a prototype since it is a
> nested matcher passed to functionProtoType() and since the function doesn't
> have a prototype, that outer matcher won't match.
Not according to the AST matcher that was implemented -- it supports
FunctionProtoType and FunctionDecl. I want to make sure that if you get to
parameterCountIs() through functionDecl() that it doesn't fail.
================
Comment at: unittests/ASTMatchers/ASTMatchersTest.cpp:4992
@@ +4991,3 @@
+ EXPECT_TRUE(matches("typedef int hasUnderlyingTypeTest;",
+ typedefDecl(hasUnderlyingType(asString("int")))));
+ EXPECT_TRUE(matches("typedef const int T;",
----------------
> I'm happy to make the improvement, but I don't know how. I simply call the
> Node.underlyingType(), just like hasType calls Node.getType(). I don't know
> why they are different.
hasType() and hasUnderlyingType() have different operational semantic
implications, at least to me. hasType() asks, "ultimately, what is the type of
this thing?", and Node.underlyingType() answers that. To me,
hasUnderlyingType() asks, "in the chain of types that this typedef refers to,
does this thing match any of them?", and Node.underlyingType() does not answer
that -- it only looks at the final desugared type. The difference we want is
that hasType() continues to look at the final type, but hasUnderlyingType()
needs to do more work to look at intermediary types and terminate that loop
when the answer is "yes, it has this type" or "no, we can't desugar any
further."
If we don't care about the intermediate types for your needs, then I don't see
the point to hasUnderlyingType() being an AST matcher at all. hasType() does
exactly what is needed, and you can instead modify that to accept a TypedefDecl
in addition to Expr and ValueDecl. However, I still see value in
hasUnderlyingType() because typedef chains can be long and complex (like in the
Win32 APIs), and being able to query for intermediary types would be useful.
e.g., I want to know about all types that have an intermediary type of DWORD
(which itself is a typedef for an unsigned integer type). hasType() will always
go to the final type, making such a matcher impossible without something like
hasUnderlyingType().
http://reviews.llvm.org/D8149
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
