recordDecl() AST matcher

[Manuel Klimek via cfe-commits]

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 <aaron at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150908/346f7601/attachment-0001.html>