<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><br></div><div><br></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><br></div><div>regards</div><div>mph</div>
</div></div>