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

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

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.

Is there any work around this? My solely goal is just to print the tree so if there is a way to do so by not using the null child that would be welcomed too.

As a side note, I would appreciate if anyone would have come across any solution to only print what is available on code on libclang and would be gentle enough to provide the code or few suggestions of functions of libclang that I could use to do so.

[1] https://gist.github.com/2503232
[2] http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/

Thank you.

Carlos Andrade

http://carlosandrade.co

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.

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]:

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 :slight_smile:
Dave.

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@rothlis.net>

I have a branch of the Clang bindings that are nearly feature complete at https://github.com/indygreg/clang/tree/python_features. However, I /think/ that tree may be busted right now, so use at your own risk.

For the past ~6 months I've been slowly moving patches from my repository into the mainline. It has been a long process. Now that I have Manuel as a reliable reviewer, things could start moving faster. I've just been busy with other projects.

If there is a particular feature missing from the in-tree Python bindings, I probably have code for it somewhere. If anyone asks kindly, I can probably fast-track specific features to the main tree.

Gregory

Thank you Gregory! I am very happy to know that! The available methods on 3.1 work just as fine on the code so I am fine for now! I might be using other functionalities in a near feature from lib clang which might not be on the current python interface so I will for sure check on this :slight_smile:

I very much appreciate your offer on fast-tracking any specific features and will keep that in mind!

Best Regards,

Carlos Andrade

http://carlosandrade.co

2012/6/18 Gregory Szorc <gregory.szorc@gmail.com>