[LLVMdev] Parsing C++ headers with Clang bindings for Python

Elliott Slaughter elliottslaughter at gmail.com
Fri Oct 18 21:29:28 PDT 2013


Answering my own question:

On Fri, Oct 18, 2013 at 8:51 PM, Elliott Slaughter <
elliottslaughter at gmail.com> wrote:

> I'd like to parse a C++ header file (say, math.h) with the Clang bindings
> for Python. (Yes, I know math.h is technically a C header, but for my
> purposes I want to pretend that it is C++.) For some reason, Clang is able
> to parse the file as C, but not as C++.
>
> Here is an example session:
>
> >>> import clang.cindex
> >>> idx = clang.cindex.Index.create()
> >>> tu = idx.parse('/usr/include/math.h', ['-x', 'c++-header'])
> >>> c = tu.cursor
> >>> for d in c.get_children():
> ...     print d.kind, d.spelling
> ...
> CursorKind.TYPEDEF_DECL __int128_t
> CursorKind.TYPEDEF_DECL __uint128_t
> CursorKind.TYPEDEF_DECL __builtin_va_list
> CursorKind.UNEXPOSED_DECL
>

It would seem that the contents on the entire module are hidden inside this
UNEXPOSED_DECL. I'd be interesting in knowing why that is, but for now at
least I seem to have solved my problem.


> >>> print len(tu.diagnostics)
> 0
>
> Now that list clearly does not represent the contents of math.h. However,
> as you can see, I don't get an error, and the list of diagnostics is empty.
>
> When I use C mode, I instead get the list of functions I'm expecting to
> see:
>
> >>> tu = idx.parse('/usr/include/math.h', ['-x', 'c-header'])
> >>> c = tu.cursor
> >>> for d in c.get_children():
> ...     print d.kind, d.spelling
> ...
> CursorKind.TYPEDEF_DECL __int128_t
> CursorKind.TYPEDEF_DECL __uint128_t
> CursorKind.TYPEDEF_DECL __builtin_va_list
> [...]
> CursorKind.FUNCTION_DECL acosf
> CursorKind.FUNCTION_DECL acos
> CursorKind.FUNCTION_DECL acosl
> [...]
>
> Am I doing something obviously wrong (aside from calling math.h a C++
> header)? Is there any reasonable way to debug problems like this?
>
> I'm on Mac OS X 10.8 using the Clang binaries from Xcode (Apple LLVM
> version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)), and Python bindings
> from Clang 3.2, and Python 2.7.2. (I am unable to test 3.3 because
> clang_Cursor_isBitField seems to be missing.)
>
> Thanks.
>
> --
> Elliott Slaughter
>
> "Don't worry about what anybody else is going to do. The best way to
> predict the future is to invent it." - Alan Kay
>



-- 
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it." - Alan Kay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/1283d1e2/attachment.html>


More information about the llvm-dev mailing list