On Wed, May 8, 2013 at 11:53 AM, Manuel Klimek <[email protected]> wrote:
> > My first gut feeling reaction is that we'll want a different solution > than to make DynTypedNode more complex, and thus less predictable. > Do you want me to take this piece into a different CL? > We had a reason for have the explicit overloads in the ASTMatchFinder > instead of just working on the interface - the problem is that you can > otherwise hand in lots of matchers that are impossible to get a match > with... > Can you give an example? Not matching a Matcher<Type> without the conversion to Matcher<QualType> seems like a bug to me. The visitor should visit the Type node. > > Things we could consider: > 1. take a DynTypedMatcher* and take ownership - together with clone(), > this allows users to do everything they need, and doesn't lead to overload > confusion. > If there is going to be a const DynTypedMatcher& overload, I think we should remove the other ones. Otherwise you could have potentially different behavior if you call the function directly or through something that uses the interface, like we see with Matcher<Type>. I'll send you a different CL with the change proposal. > 2. only have the DynTypedMatcher interface, and somehow break > dynamically with an error message > other ideas? > > http://llvm-reviews.chandlerc.com/D714 > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
