[cfe-dev] using libclang with an incomplete header file

[Sean Larsson]

I'm using libclang + python bindings to try to extract information about
functions and their parameters from a header file. However, the header file
I'm working with is incomplete: it's missing many typedefs used in the
function declarations. I'm trying to build up a list of all the missing
types, but am having some difficulties. Here is a reduced example of the
problem I'm having:

void f1(int);
void f2(bah);
void f3(int, bah);

'bah' is an undefined type.

The issue I'm having how to determine if 'bah' is an undefined type. When I
dump the tree for the above header, I get this:

headers/undefined_vs_int.h (TRANSLATION_UNIT)
  +--f1 (FUNCTION_DECL)
  |  +-- (PARM_DECL)
  +--f2 (FUNCTION_DECL)
  +--f3 (FUNCTION_DECL)
     +-- (PARM_DECL)
     +--bah (PARM_DECL)

What's odd to me is that 'f2' has no children, but 'f3' does. If I swap the
order of 'int' and 'bah' in f3, then it will have no children. So, it seems
that the error of not having 'bah' defined will short circuit the parsing
of the rest of the function declaration if it comes first in the argument
list. But if it comes after a valid type, 'bah' winds up being converted to
an integer, and I cannot figure out any way to determine when that occurs.
Additionally, if I add more arguments to f3 after 'bah', they will be
parsed fine and added to the tree.

This is throwing me for a loop, as I'm trying to parse a very large header
file with a number of types that are undefined (I plan on adding them once
I have a collection of exactly what is missing). But right now, it's
impossible for me to trust the output I'm getting since it seems to
different depending on where the first undefined type is in the argument
list.

FYI, the tree dumping code is this:

        print asciitree.draw_tree(tu.cursor,
                                    lambda n: list(n.get_children()),
                                    lambda n: "%s (%s)" % (n.spelling or
n.displayname, str(n.kind).split(".")[1]))

Is this a use case for which libclang is not suited?

Thanks,

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150523/837c8d61/attachment.html>