Hey,

I'm happy to announce that I've been accepted as student for this year's Google Summer of Code! This summer, I'll have the chance to improve the Clang integration in KDevelop, something we (the KDevelop developers) have been working on for some months already.

Project Introduction

Milian's blog post from two months ago pretty much explains all you need to know about the current situation regarding C/C++ language support in KDevelop.

A quick recap:
KDevelop's current C++ language support plugin basically implements a fully custom C++ parser frontend, in about 55 KLOC of code. This includes an implementation of a C Preprocessor (about 4 KLOC) the actual C++ parser (about 15 KLOC) and a whole lot of glue code to transform all that in a meaningful representation for the user. As you can imagine, this is a real maintenance nightmare. Our bug tracker is full of entries containing code snippets where our custom C++ parser just fails. Fixing each of those and/or adding support for more complex language features such as C++11 lambdas, variadic templates, etc. is extremely difficult and error prone.

Using Clang to actually do the heavy-lifting for us was a long-standing idea. A few months ago, that idea actually began to take shape, when Olivier JG started playing around with Clang's C API (provided by libclang) in kdev-clang. kdev-clang aims to integrate Clang into KDevelop for C/C++/Objective-C language support.

The benefit is immense -- Citing Milian: "(Now) we can actually concentrate on making our IDE shine instead of playing catchup with the compiler."

Current State

The Clang language plugin already supports:

• Parsing of full projects, supporting all C++ features that Clang supports
• Semantic highlighting
• Code browsing
• Basic code completion, including macros

• Support for Clang diagnostics [implemented by me]
• Support for Clang fixits (they are the solution approaches to common errors) [implemented by me]

Open Tasks

DUChain integration

• Qt Integration: Oldcpp has some extensions for improved Qt support. Examples are support for the Q_PROPERTY(...) declarations which are parsed by Qt's MOC, but expand to nothing in C++. Olivier Goffart did some investigations in that regard, and showed that clang can be made to work with this, see http://woboq.com/blog/moc-with-clang.html. In order to provide a good user-experience for Qt/C++ developers, we should be able to provide context browsing inside the Q_PROPERTY(...) macro. Other interesting stuff: Support the new signal-slot syntax in Qt5 properly.

• Macro support: When hovering over macro uses oldcpp shows macro definition location, the original macro text plus the expanded preprocessed text. This is currently missing in clangcpp – would be nice to get this back. Oldcpp also offers to navigate inside the preprocessed text, something we'd want back as well.

• Include navigation: Allow to browse includes again (triggered by hovering of #include <somefile> directives and similar)

Code completion

• Code completion: This is work-in-progress at the moment, so it is left to see at what state we are when GSoC begins. Currently some things are still missing, such as “virtual override completion”. Also the automatic replacement of . to -> and vice-versa in case of pointer/non-pointer types is still missing.

• “Implement function” feature: If a function is only declared but not defined, we offer a "implement function" helper item in the code completion. This is currently not yet ported to clangcpp.

• "Switch to Definition/Declaration” feature: If the cursor is at some declaration in a header file, KDevelop offers a shortcut to automatically switch to its definition in the source file (opening the corresponding file in the active view). This is not yet possible in clangcpp.

• Show viable expressions for current context: When inside a function call or constructor call, show viable expressions which fit the signature of the current argument. Example: int i = 1; char* str = “c”; strlen( – this should show variable str in the completion popup as best match.

• Include completion: Oldcpp offers completion hints when attempt to #include some file, port this to clangcpp.

Assistants / Refactoring

• Rename assistant: When you change a local variable name, this assistant renames all uses of it, too. This feature is mostly non-language-agnostic, so it makes sense to refactor it in a way it gets available for all supported languages. Currently, this feature is only available in oldcpp, being less useful than it could be.

• Adapt signature: Similar to above – when changing the signature of a function at the declaration/definition, this offers adapting the corresponding defintion/declaration signature. This probably doesn't fit for a non-language-agnostic assistant (because of C++-specific bits required when adapting signatures), hence we need to port this over from oldcpp to clangcpp.

• Declare function/member/variable: When you use some undeclared function/member/variable, we offer you to create a private/public/local declaration of that as appropriate.

• Rename File: When you rename a class and the file it was declared in matches the old identifier, we offer you to rename the file in accordance.

Other tasks

• Refactoring (libtooling): Clang provides a complete infrastructure for writing standalone tools for inspecting or manipulating code, available in libtooling. The FrontendAction class reference provides a list of readily available actions that can be performed by the frontend and which already might be useful for use once we're able to run them.

• Microsoft Windows integration: LLVM/Clang works on Windows, too. Make sure we're able to compile the Clang-based C++ language support plugin on Windows and that the Windows version is feature-compatible with the Linux version.

• Selecting standard version: Be able to define the version of the C/C++ standard (e.g. c++03, or c++11, etc.) used for parsing the source files. The C/C++ version for a specific project can be retrieved via our CMake integration or could be explicitly set by the user via the GUI.

Final words

I'm really excited about my project and I hope to get kdev-clang into a state where it's usable by early adopters. Personally, I'm really looking forward to having a complete and working C/C++ support (including all the new C++11 features) and superb Clang diagnostics.

With these features in place, you can be pretty much sure that if KDevelop/Clang says your code is fine, then actually compiling it won't reveal any further compilation issues.

Thanks!