<div class="gmail_quote">On Sun Sep 28 2014 at 1:47:19 AM Steven Lu <<a href="mailto:stevenlu443@gmail.com">stevenlu443@gmail.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">Hi,<div><br></div><div>I have a rather basic conceptual question for the clang experts out there. I am starting out and the examples and tutorials that exist have been very helpful to let me get to the point where I can find all the details about all class/struct/union declarations (with VisitCXXRecordDecl()), and also I am able to enumerate all the fields inside of such items by using VisitFieldDecl(). </div><div><br></div><div>My question is related to the apparent difficulty of directly navigating the AST as opposed to using callbacks on the RecursiveASTVisitor. I reckon that this difficulty might be the motivation behind the design of RecursiveASTVisitor itself, but nevertheless it is restrictive. </div><div><br></div><div>For example: When looking at the output of ast-dump for some code, I can see that there are CXXRecordDecls shown as children of TemplateDecls. Supposing I want to enumerate just the TemplateDecls, it is straightforward to implement RecursiveASTVisitor::VisitTemplateDecl(), but I have been having a very difficult time retrieving any pointer to TemplateDecl from within VisitCXXRecordDecl. Indeed CXXRecordDecl::getParent() yields a DeclContext*, yet TemplateDecl's aren't even DeclContexts, AFAICT. The deep AST class hierarchy is making this difficult.</div><div><br></div><div>So the next best attempt I can make is to use the SourceManager's tools to help me narrow down if these separate TemplateDecls and CXXRecordDecls that I find are referring to the same source code locations. This is done manually by comparing actual source location values: If a TemplateDecl and CXXRecordDecl share a location, then I can join together the information that I find (e.g. whether the class/struct is empty and the text list of the template parameters).</div><div><br></div><div>This is moderately straightforward, but much less so than directly using AST traversal to achieve such a correlation. </div><div><br></div><div>So hopefully someone can shed some light for me on why this is how it is, and what might perhaps be a better way to establish information about the decl's that are found in the code. In particular, why is it that I can easily and reliably query the CXXRecordDecl to see if it is a template specialization, and similarly easy to query any given FieldDecl for its (CXX)RecordDecl context, but not at all easy to see if a particular CXXRecordDecl happens to be a template declaration. </div></div></blockquote><div><br></div><div>I wasn't there when this was implemented, but I'd say it's the way it is because of engineering trade-offs. Putting a single common interface just for traversal in only helps in a small subset of cases. On the other hand, the RAV is of course a pretty complex beast :)</div><div><br></div><div>We have tried to build something for tool writers that makes it easier to find stuff in the AST, which is called the AST matchers:</div><div><a href="http://clang.llvm.org/docs/LibASTMatchers.html">http://clang.llvm.org/docs/LibASTMatchers.html</a><br></div><div><br></div><div>To your specific problem: if I understand you correctly, you want the ClassTemplateDecl, which nicely points to the CXXRecordDecl that describes the template.</div><div><br></div><div>Cheers,</div><div>/Manuel</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks.</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>