Version: (using Devel) Installed from: Compiled sources LLVM is a very decent compiler framework providing a JIT, an intermediate representation and various assorted goodies. Relatively recently they decided that they would really like to have a frontend too that is: * Faster than gcc (up to much faster) * Implemented in readable C++ and available as separate libraries * Well documented and supported. They already have an (almost) 100% conformant preprocessor available as a separate library and parsers for C and ObjC and a tiny bit of C++. Both LLVM and clang (the frontend) are BSD licensed. clang is already being used to implement various static analysis tools for C code and is starting to gain in popularity. Kdevelop has a nice C++ parser which is something clang probably won't have perhaps for a couple of years even though they started attracting contributors like e.g., doug gregor and IIRC members of the boost community. It seems to me that there exists a great opportunity here for the kdevelop community to interact more closely / join forces with LLVM/clang to create the 'best C/ObjC/C++ parser ever' at least for IDE purposes. Since most/all of the clang contributors are compiler people this could help with kdevelop's manpower issues at least in this front. Clang is also IIRC intended to be embedded on an IDE (XCode) at least eventually so changes requested by kdevelop to e.g., have better incrementality in parsing or multiple threads or whatever will probably be accepted in clang. Also, clang and kdevelop's parser have pretty similar design, clang devs actually seem to have looked at kdevelop's parser sources but discarded it because it had no comments and thus was hard to understand and evaluate. But with the help of kdevelopers that could change :) This is all just IMHO, but modern IDE problems (static/dynamic analysis/refactoring) are pretty hard, so it helps to have as large a community as possible to stay competent.
The actual "parser" is the smaller problem. It has relatively few bugs, and seems to implement nearly all of C++. The bigger problem is what you do with the parsed data, eg. the "semantic" part. KDevelop has the DUChain, a language-independent architecture to store/manage/use exactly that data, and it's now being worked on for years. That architecture is in no way useful for a compiler, rather it's an abstraction optimized for persistence, generality, and "updatability", which means that for example the data of included headers is stored separately from the files that include it. On the parser level, KDevelop4 does have a parser that implements nearly all of C++, and has few known bugs. Those bugs are hard to fix, because the author isn't active any more and the code is hard to understand, but that effort is not comparable to switching the parser. So it would be nice if some more efforts could be shared, but I don't see a realistc way for it at this point.
Decoupling the c++ parser itself from DUChain could probably be done with realistic effort. More so because (correct me if I'm wrong) this seemed to be the case at one point. I think for example Krazy and Umbrello would welcome a complete and maintained parser as well. The dependency on Qt4 is another story though. Off course this is not going to happen unless anyone actually does it and at the same time makes sure DUChain performance stays identical.
The parser is pretty much independent of the rest. The Ast nodes do have DUContext members on them, which is needed for DUChain, but that can easily be removed. Umbrello developers already use KDevelop's C++ parser, though I think its the one from KDevelop3 and they started to move from that parser into a generated one (can't recall which tool they decided to use) for maintainability. However IIRC both Roberto and Jakob Petsovis said that creating a C++ parser from with a parser generator is pretty hard. Anyway, as David made clear the idea of this wishlist report is basically a wontfix because a compiler and an IDE-integration for C++ have very different goals and hence structures.