+Sam, who wrote the dynamic AST matchers, and Peter, who wrote the clang-query tool which is already in clang-tools-extra.<br><br><div class="gmail_quote">On Mon Dec 29 2014 at 11:28:23 PM mobi phil <<a href="mailto:mobi@mobiphil.com">mobi@mobiphil.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>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: </div><div><br></div><div>cmatch -a SemaDecl.ast \ <br></div><div><div> -m "methodDecl(returns(pointsTo(hasDeclaration(recordDecl(isDerivedFrom(recordDecl(hasName(\"Decl\"))))))))" \</div><div> -r getParent.getNameAsString.dump</div></div><div><br></div><div>I will make the source code as soon as possible public.</div><div>In the source code, the methods are added/defined in some special header files with macros in the form of.<br></div><div><div><br></div><div>METHOD(Decl, getDeclKindName, char)</div><div>METHOD(Decl, dump, void)</div><div>METHOD(Decl, dumpColor, void)</div><div>METHOD(NamedDecl, getNameAsString, string)<br></div><div>METHOD(RecordDecl, getPreviousDecl, Decl)<br></div><div>METHOD(RecordDecl, getMostRecentDecl, Decl)</div><div>METHOD(RecordDecl, hasVolatileMember, bool)</div><div>METHOD(FunctionDecl, getBody, Stmt)<br></div><div>METHOD(FunctionDecl, getDeclName, DeclarationName)</div><div>METHOD(FunctionDecl, getReturnType, QualType)</div><div>METHOD(CXXMethodDecl, getParent, Decl)<br></div><div><br></div></div><div>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. </div><div>The tool can also be called by zsh completion mechanism to complete the ast expression.</div><div><br></div><div>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)</div><div><br></div><div>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:</div><div><br></div><div><b>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. </b></div><div><b><br></b></div><div>Optional<DynTypedMatcher> matcher = Parser::parseMatcherExpression(<br></div><div><div><div> StringRef(expr), nullptr, namedValues, &diag);</div><div><br></div></div><div>would be nice to have something like matcher->getReturnKind() similar to matcher->getSupportedKind()</div><div><br></div><div>Question:<br></div><div>is there a way to find back this information?</div><div><br></div><div><b>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></b></div><div><br></div><div>I understand that the "narrowing matchers" like isDerivedFrom would have return type Matcher<CXXRecordDecl> and not Matcher<Decl>. </div><div>Question: Any reason for this inconsistency?</div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><b>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.</b></div><div><br></div><div>Question: was this intentionally implemented so? </div></div></div></blockquote><div><br></div><div>Yes, but that was a stupid idea back at the time (it was mine, so I can call myself stupid without being too offensive :)</div><div>We should rename it to cxxRecordDecl.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br></div><div>regards</div><div>mph</div>
</div></div>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</blockquote></div>