[cfe-dev] [libclang] Is there any method like get_children (python cindex) available for libclang or alternative to print the tree structure by the traversal method?

[Carlos Andrade]

Thanks David!

I was able to narrow down the problem yesterday night. What I believe that
was causing the strange error on my mac was that llvm+clang 2.9 did not
have some methods listed on the bindings from clang. The problem was that
mac-os was complaining about something else instead of telling me that. I
run that on a Ubuntu and Debian os on my virtual machine and after moving
from 2.9 to 3.0 and finally to 3.1 I finally was able to observe the Debian
os complaining about the lack of the function being imported on llvm+clang
2.9 and notice by 3.1 the problem was solved. Curiously enough the llvm 3.1
on Debian did not work either, but when I moved back to llvm 3.1 on
asserts+debugs on my mac it finally run the code without any modification.

I am actually grateful for finding the interface on Python since even some
things I couldn't make sense on the Doxygen on how to use (there are not
many working examples floating around of lib clang nor the python
interface), I found how their meaning from the comments written on the
Python interface.

I am still wondering thou on how to print a tree on the C version as to
identify something that mimics the get_children from python or at the very
least let me know when it hits a leaf, but the Python solution work just as
fine.

Please let me know if you want any more details in respect to this matter,
I would be glad to provide of any of the os or the llvm+clang versions.

Best Regards,

Carlos Andrade
http://carlosandrade.co



2012/6/18 David Röthlisberger <david at rothlis.net>

> On 17 Jun 2012, at 17:45, Carlos Andrade wrote:
> >
> > Hi David, thanks for replying.
> >
> > Yes I did narrow down the problem to a more specific line, if I run this
> code which was provided at [2] and I adapted a small piece of [1]:
> >
> > -----
> > import sys
> > import clang.cindex
> >
> > def callexpr_visitor(node, parent, userdata):
> >    if node.kind == clang.cindex.CursorKind.CALL_EXPR:
> >        print 'Found %s [line=%s, col=%s]' % (
> >                clang.cindex.Cursor_displayname(node),
> node.location.line, node.location.column)
> >    return 2 # means continue visiting recursively
> >
> > index = clang.cindex.Index.create()
> > tu = index.parse(sys.argv[1])
> > #clang.cindex.Cursor_visit(
> > #        tu.cursor,
> > #        clang.cindex.Cursor_visit_callback(callexpr_visitor),
> > #        None)
> > print 'Translation unit:', tu.spelling
> > f = tu.get_includes()
> >    print 'test'
> > ------------------
> > Adding the method in red makes it crash, That is, the tu.get_includes
> crashes. I look at the cindex.py but I cant figured what is wrong it seemed
> to me like a normal use of the method.
>
> Sounds like a bug to me -- you could raise it in the clang bugtracker.
> Though first you should check that it hasn't been fixed already; you'd
> have to build from the latest sources and test against that.
>
> If you do raise a bug, make sure you minimise the failing code to the
> smallest possible test case (there's no need for the callexpr_visitor,
> or the commented-out code). You will also need to include the C++ code
> that you parse with your tool, because the bug may only happen with
> certain inputs. Again, reduce this code sample to the absolute minimum
> that will still trigger the bug.
>
>
> > The reasons I stayed on C was because I saw few comments that python was
> still catching up on making available the methods provided by libclang,
>
> That's true in the sense that any new feature must be added to the C
> interface before it can be added to the python bindings; that is just
> the nature of foreign bindings. But I don't know how far behind the
> python bindings are currently lagging (if at all). Gregory Szorc (CCd)
> is one of the maintainers of the python bindings -- perhaps he can
> comment.
>
> Good luck :-)
> Dave.
>
>
> > 2012/6/17 David Röthlisberger <david at rothlis.net>
> > On 17 Jun 2012, at 08:24, Carlos Andrade wrote:
> >>
> >> I managed to create a transversal using libclang on C, map it to code
> and get its types but now I am stuck trying to output it like a tree like
> it is done at [1]. For some unknown reason [1] crashes here with the
> warning "Python quit unexpectedly while using libclang.dylib plug-in.
> (Running on an OS Lion).
> >>
> >> [1] https://gist.github.com/2503232
> >
> > Can you narrow down the failure to a specific line of python + line of
> > the input translation unit? I suspect it might be something to do with
> > accessing a property of an invalid type.
> >
> >> On my C version I can get each node being printed, but what I wanted is
> what [1] does: Print the structure of the tree (who is child of who) and I
> was trying to do so by tying to verify if the child is NULL but I cant find
> any method available to do so. [2] Seems to suggest this doesnt even exist
> on libclang C.
> >>
> >> [2]
> http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/
> >
> > Have you considered writing your program in python? I found that using
> > the ipython shell (with its tab-completion) was really helpful for
> > exploring the libclang API.
> >
> > (I apologise for not actually answering your question, but I don't know
> > enough about the libclang C interface.)
> >
> > Cheers
> > Dave.
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120618/0b405fc0/attachment.html>