[cfe-dev] Hacking advice

[Reid Kleckner]

Not true, unless it's changed significantly since I used it.  You only
need to override the methods corresponding to the bits of the AST that
you're interested in.  You should be able to just ignore templates if
you don't care about them.  IMO it's really what you want for walking
the AST.

Reid

On Sat, Nov 6, 2010 at 12:26 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote:
> Again, I believe RecursiveASTVisitor is for templates more than anything
> else. Look at the methods defined to be overridden:
> bool shouldVisitTemplateInstantiations()
> bool TraverseDecl(Decl *D)
> bool TraverseNestedNameSpecifier(NestedNameSpecifier *NNS)
> bool TraverseTemplateName(TemplateName Template);
> bool TraverseTemplateArgument(const TemplateArgument &Arg);
> bool TraverseTemplateArgumentLoc(const TemplateArgumentLoc &ArgLoc);
> bool TraverseTemplateArguments(const TemplateArgument *Args, unsigned
> NumArgs);
> bool TraverseConstructorInitializer(CXXBaseOrMemberInitializer *Init);
> Five out of eight deal with templates. The other ones like constructor
> initialization does not suite my needs and TraverseDecl can be handled by
> the ASTConsumer.
> The other functions have been macroed to a point of un-readability. Those
> macros hang out in "clang/AST/*.def" and were probably created by some
> little language cover all the cases.
> Jeff
>
>
> On Sat, Nov 6, 2010 at 12:16 PM, Garrison Venn <gvenn.cfe.dev at gmail.com>
> wrote:
>>
>> I believe HandleTopLevelDecl, although a little too low level works, since
>> every thing is a Decl
>> (see http://clang.llvm.org/doxygen/classclang_1_1Decl.html), and from
>> Decls one can get statements
>> and therefore expressions
>> (see http://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html for
>> example).
>> Having said this I believe utilization of a visitor is more practical, and
>> therefore use of RecursiveASTVisitor
>> more viable.
>> Garrison
>> On Nov 6, 2010, at 9:06, Jeff Kunkel wrote:
>>
>> The overall goal would be
>> 1: parse the names, return types, and parameters of functions with a given
>> context like a namespace, class, struct or global scope.
>> 2: parse classes, structs, enums, etc for the name, internal objects,
>> members, member methods, virtual overrides, inheritance, etc.
>> 3: The final output would be the boost::python C++ code wrapper with as
>> descriptive an interface as the C++ class itself.
>> Thanks,
>> Jeff Kunkel
>>
>> On Sat, Nov 6, 2010 at 12:02 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote:
>>>
>>> I've been studying ASTConsumer and RecursiveASTVisitor.  The easiest way
>>> to find objects, structs, class, enums, etc is clearly
>>> "HandleTagDeclDefinition" from ASTConsumer (see the function documentation).
>>> However, I still need to be able to gather global functions or functions
>>> local to a namespace.
>>> I am looking at "HandleTopLevelDecl" within the ASTConsumer, but it seems
>>> to be geared for data declartion like "int x,y;". I am not 100 percent sure
>>> that it handles function definitions as well.
>>> Second, ASTContext is a very general class, and it is a bear to parse
>>> through to find what I need. It seems that I could forgo the methods
>>> described above, and I could just use "HandleTranslationUnit" if I wanted to
>>> parse through the ASTContext.
>>> RecursiveASTVisitor looks geared for
>>> template declarations and instantiations. It does not seem viable for the
>>> common function definitions, and it seems inept to handle class, struct,
>>> etc instantiations.
>>> Any other advice or comments?
>>> - Thanks
>>> - Jeff Kunkel
>>>
>>> On Sat, Nov 6, 2010 at 11:33 AM, David Chisnall <csdavec at swan.ac.uk>
>>> wrote:
>>>>
>>>> On 5 Nov 2010, at 21:16, Jeff Kunkel wrote:
>>>>
>>>> > I need to gather or visit the classes, methods, and functions defined
>>>> > within a give clang compiler instance. Is there a simple interface to
>>>> > accomplish this?
>>>>
>>>> This depends on what you wish to accomplish.  The simplest interface is
>>>> via libclang, but it doesn't expose all of the details of the AST.
>>>>  Alternatively, you can use the AST visitor or consumer interfaces.  The
>>>> best approach depends on the level of detail that you need.
>>>>
>>>> David
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>