aaron.ballman added a comment.
In http://reviews.llvm.org/D19871#420095, @etienneb wrote:
> > I agree that when possible, matchers should be available via the dynamic
> > matchers API. It doesn't seem overly complicated to add this support here.
> > As far as I understand, we just need to register the matcher in
> > lib/ASTMatchers/Dynamic/Registry.cpp and add support for `CastKind`
> > argument type (by adding a corresponding `ArgTypeTraits` instantiation).
> > Etienne, can you try this?
>
>
>
>
> 1. The parameter is passed as a string (which is not the case for the
> hasCastKind matcher): hasAttr("attr::CUDADevice").
Correct. The dynamic registry has no support for enumerations of values, and so
it uses strings instead. I think that's fine here as well.
> 2. There is no easy way to list every cast kind. Which means we need to
> hardcode them (or iterate over the domain) [both solution sounds terrible to
> me]. ``` static clang::CastKind getCastKind(llvm::StringRef AttrKind) {
> return llvm::StringSwitch<clang::CastKind>(AttrKind) .Case("CK_Dependent",
> CK_Dependent) [...] <<-- list every cast kind here.
> .Default(clang::CastKind(-1)); } ```
This is unfortunate, but is likely the way we would move forward.
> So even if the above solution is working, we still need to call it that way
> (as a string):
> clang-query> match castExpr(hasCastKind("CK_Dependent"))
Correct, that's expected behavior for clang-query (though I would love if
someday we could expose actual enumerations somehow instead of string literals).
http://reviews.llvm.org/D19871
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
