etienneb added inline comments.
================
Comment at: lib/ASTMatchers/Dynamic/Marshallers.h:102
@@ +101,3 @@
+ static clang::CastKind getCastKind(llvm::StringRef AttrKind) {
+ return llvm::StringSwitch<clang::CastKind>(AttrKind)
+ .Case("CK_Dependent", CK_Dependent)
----------------
aaron.ballman wrote:
> This might be an awful idea, but let's explore it.
>
> What if we moved the CastKind enumerator names into a .def (or .inc) file and
> use macros to generate the enumeration as well as this monster switch
> statement? We do this in other places where it makes sense to do so, such as
> in Expr.h:
> ```
> enum AtomicOp {
> #define BUILTIN(ID, TYPE, ATTRS)
> #define ATOMIC_BUILTIN(ID, TYPE, ATTRS) AO ## ID,
> #include "clang/Basic/Builtins.def"
> // Avoid trailing comma
> BI_First = 0
> };
> ```
Does the dynamic matching is used somewhere else than clang-query?
I wonder the impact of refactoring to support them if it's barely used.
It can't be worse than before as it wasn't supported at all (the matcher didn't
exists).
I believe there is a larger cleanup to do to support correctly dynamic matcher
like "equals".
And, this case is one among others.
I'm not a fan of this huge switch that may just get out-of-sync with the
original enum.
I'm still in favor of adding this matcher to the unsupported list until we push
the more complicated fix.
[which may fall in my plate anyway]
Any toughs?
http://reviews.llvm.org/D19871
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
