[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?

David Röthlisberger david at rothlis.net
Mon Jun 18 10:13:38 PDT 2012

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

Good luck :-)

> 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.

More information about the cfe-dev mailing list