[cfe-dev] Hacking advice
Jeff Kunkel
jdkunk3 at gmail.com
Sat Nov 6 10:12:29 PDT 2010
Ok, I will take another look at it. On closer inspection, I see more of the
interface I skipped before.
So to gain the function declarations, I would hook into TraverseDecl. Would
I use TraverseDecl for object definition too? And how do I know what scope I
am in?
On Sat, Nov 6, 2010 at 12:51 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote:
> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101106/45b139f5/attachment.html>
More information about the cfe-dev
mailing list