[cfe-dev] ast matchers, structDecl, unionDecl missing? recordDecl is only for CXXRecordDecl

[Manuel Klimek]

+Sam, who wrote the dynamic AST matchers, and Peter, who wrote the
clang-query tool which is already in clang-tools-extra.

On Mon Dec 29 2014 at 11:28:23 PM mobi phil <mobi at mobiphil.com> wrote:

> Hi,
>
> I came across some problems I will describe below while I was
> designing/implementing some new libclang functions. These functions are a C
> interface (and interface for scripting languages) to query ast with text
> based matchers. On top of these functions I also wrote a tool that can
> query ast with matchers and can call a chain of methods on the retrived Ast
> nodes, like:
>
> cmatch -a SemaDecl.ast \
>           -m
> "methodDecl(returns(pointsTo(hasDeclaration(recordDecl(isDerivedFrom(recordDecl(hasName(\"Decl\"))))))))"
> \
>           -r getParent.getNameAsString.dump
>
> I will make the source code as soon as possible public.
> In the source code, the methods are added/defined in some special header
> files with macros in the form of.
>
> METHOD(Decl, getDeclKindName, char)
> METHOD(Decl, dump, void)
> METHOD(Decl, dumpColor, void)
> METHOD(NamedDecl, getNameAsString, string)
> METHOD(RecordDecl, getPreviousDecl, Decl)
> METHOD(RecordDecl, getMostRecentDecl, Decl)
> METHOD(RecordDecl, hasVolatileMember, bool)
> METHOD(FunctionDecl, getBody, Stmt)
> METHOD(FunctionDecl, getDeclName, DeclarationName)
> METHOD(FunctionDecl, getReturnType, QualType)
> METHOD(CXXMethodDecl, getParent, Decl)
>
> Will need to generate (also with matchers) the full list of "usable"
> methods in form of such declarations that can be compiled into my library.
> The tool can also be called by zsh completion mechanism to complete the
> ast expression.
>
> The above functionality is implemented, I can add almost all methods that
> have void parameters to all subclasses of Decl, Stmt, Type and some POD
> kind structures. (SourceLocation, QualType, etc)
>
> The next feature I wanted to add is shell completion mechanism for the
> chain of methods that can be called on the matched ast nodes. Unfortunately
> I bumped into the following little annoyances:
>
> *1.a it is impossible to deduce the "inner" type that will be returned by
> a matcher, so that I can deduce the list of methods. *
>
> Optional<DynTypedMatcher> matcher = Parser::parseMatcherExpression(
>          StringRef(expr), nullptr, namedValues, &diag);
>
> would be nice to have something like matcher->getReturnKind() similar to
> matcher->getSupportedKind()
>
> Question:
> is there a way to find back this information?
>
> *1.b there is some information about the return type, but that is in case
> of recordDecl for instance is Matcher<Decl>,  and not Matcher<RecordDecl>*
>
> I understand that the "narrowing matchers" like isDerivedFrom would have
> return type Matcher<CXXRecordDecl> and not Matcher<Decl>.
> Question: Any reason for this inconsistency?
>

This is not an inconsistency - the return type is always the type on which
you want to be able to run the matcher. And a type matcher like recordDecl
is one you want to run on all Decls to see whether they are actually record
decls.


> *2. delving more into the source code to find out 1.b (and tested) I found
> that recordDecl matches only CXXRecordDecl, thus for C programs one cannot
> match-find structures/unions.*
>
> Question: was this intentionally implemented so?
>

Yes, but that was a stupid idea back at the time (it was mine, so I can
call myself stupid without being too offensive :)
We should rename it to cxxRecordDecl.


>
> regards
> mph
>  _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150103/74084d42/attachment.html>