[cfe-dev] index library

John McCall rjmccall at apple.com
Tue Jan 5 18:57:34 PST 2010


On Jan 5, 2010, at 5:51 PM, Andrew Sutton wrote:

> I spent yesterday morning hacking out a Python wrapper for the CIndex library (using ctypes). It seemed like a quick and easy way to pull data from C/C++ files... It's very much a first attempt. Probably not great, but it seems to work so far. I can make the code available if anybody's interested. Anyhow, I ran into a couple of problems that I couldn't quite resolve on my own.
> 
> When I tried to compile a simple program with some templates (clang -emit-ast), clang fails with an 'Unexepcted DeclType', which I've taken to mean that PCHWriter (and probably PCHReader) don't support the necessary visitors for TemplateDecl or Decl's with associated TemplateDecls.
> 
> I was going to take a shot at encoding templates into PCH's when I realized that I have absolutely no idea what is actually supposed to go into a PCH or AST file. In fact, it didn't like there was a lot support for C++ Decls in the PCHWriter/Reader. I was just curious what the plans are for these AST objects. Are there any? What needs to be supported?

You're absolutely right that there is minimal support for C++ AST objects in the PCH routines right now.  It's a known problem which blocks a lot of interesting feature work, and we'll definitely need to fix it sooner rather than later;  unfortunately, at the moment most of us are occupied on other tasks, like getting clang to self-host.  If you're interested in working on it, that would be fantastic.  Most C++ nodes have settled down enough for PCH support to be usefully added in parallel.

The PCH record for an AST node stores everything that you'd see in the corresponding class.  Most of the work is mechanical:  PCHWriter adds entries to a record, and PCHReader pulls those entries back out in the same order.  If we could do this with reflective meta-programming, we would. :)

I believe that we are not currently interested in maintaining PCH forward/backward compatibility.

John.



More information about the cfe-dev mailing list