Yea, we had that discussion a few times, and I can never remember why we ended up in the state we're in. We definitely had a time where we switched to just using the exact same name as the node's class name for the matchers. I *think* we didn't do it for cxxRecordDecl, because Richard said that's a relic we should get rid of anyway, but I'm not sure.
On Fri, Sep 4, 2015 at 8:32 PM Aaron Ballman <aa...@aaronballman.com> wrote: > It turns out that the recordDecl() AST matcher doesn't match > RecordDecl objects; instead, it matches CXXRecordDecl objects. This > is... unfortunate... as it makes writing AST matchers more complicated > because of having to translate between recordDecl()/CXXRecordDecl. It > also makes it impossible to match a struct or union declaration in C > or ObjC. However, given how prevalent recordDecl()'s use is in the > wild (I'm guessing), changing it at this point would be a Bad Thing. > > For people trying to write AST matchers for languages like C or ObjC, > I would like to propose adding: > > structDecl() > unionDecl() > tagDecl() > > These will match nicely with the existing enumDecl() AST matcher. > > Additionally, I would like to add cxxRecordDecl() to match > CXXRecordDecl objects. While it duplicates the functionality exposed > by recordDecl(), it more clearly matches the intention of which AST > node it corresponds to. > > Finally, I would like to undocument recordDecl() and change our > existing documentation and AST matcher uses to use > cxxRecordDecl/structDecl() instead. Maybe someday we can deprecate > recordDecl() more officially. > > I'm open to other ideas if there are better ways to move forward. If > you think changing the meaning of recordDecl() is acceptable, I can > also go that route (though I would still propose adding unionDecl() > and cxxRecordDecl() in that case). > I think changing recordDecl is acceptable. I believe very few tools will actually start doing wrong things because of it. I'd like more opinions first, though :) > > Thanks! > > ~Aaron >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
