[PATCH] D24361: hasDeclaration(qualType(...)) matcher should unwrap ElaboratedType and TemplateSpecializationType
Manuel Klimek via cfe-commits
cfe-commits at lists.llvm.org
Mon Oct 24 00:51:02 PDT 2016
klimek added inline comments.
================
Comment at: unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:2119
+ "template <typename U>\n"
+ "void Function(Namespace::Template<U> param) {\n"
+ " param.Method();\n"
----------------
lukasza wrote:
> klimek wrote:
> > Given your use case: why do we need hasDeclaration here at all?
> > I'd have expected this working with just matching on the nested name specifier of the type instead of saying hasDeclaration on the template type.
> > Btw, if you add a type alias for a class not in the namespace into the namespace (typedef / using), do you wan that to rename or not? :)
> >
> > I'd personally probably have expected (2), but I'm never sure in these cases without playing around with more test cases...
> > Given your use case: why do we need hasDeclaration here at all?
> > I'd have expected this working with just matching on the nested name specifier of the type instead of saying hasDeclaration on the template type.
>
> Because I want "namespace-of-user-provided-declaration" matching to work both for ElaboratedType nodes (with explicit nested name specifier) and for other kinds of nodes (where there might be no nested name specifier). I was hoping that I could do this with a single hasDeclaration matcher, rather than listing all possible type nodes myself (when building my own matcher) like I sort of do in a workaround. In particular, after this CL a single, simple hasDeclaration-based matcher can be used in
> // auto blink_qual_type_base_matcher =
> // qualType(hasDeclaration(in_blink_namespace));
> inside https://codereview.chromium.org/2256913002/patch/180001/190001.
>
> > Btw, if you add a type alias for a class not in the namespace into the namespace (typedef / using), do you wan that to rename or not? :)
>
> Good question. I want a rename to happen if I have ::SomeOtherNamespace::Typedef resolving to ::NamespaceWithRenamedMethods::Class, but I do not want rename to happen if I have ::NamespaceWithRenamtedMethods::Typedef resolving to ::SomeOtherNamespace::Class. I guess my current hasDeclaration-based matcher will match both cases :-( One way to fix this would be to exclude typedefs in |decl_under_blink_namespace| at https://chromium.googlesource.com/chromium/src/+/14d095b4df6754fa4e6959220b2b332db0b4f504/tools/clang/rewrite_to_chrome_style/RewriteToChromeStyle.cpp#646
>
> But... this question+answer should have no impact on the CL under review, right?
>
> > I'd personally probably have expected (2), but I'm never sure in these cases without playing around with more test cases...
>
> Ok. This (#2) is what the current patch results in.
You're right that regardless of what the right solution for your tool is, we should close this hole :)
Richard, can you elaborate on why you would have expected (3) to happen? I'm reluctant to put something into the matchers that you think is unexpected...
https://reviews.llvm.org/D24361
More information about the cfe-commits
mailing list