Hey,

In the first two weeks of my GSoC I've spent time on moving out lots of code from the current C++ language support into kdevplatform (the base of KDevelop, which contains all the non-language agnostic, reusable components for the IDE).

Task recap: 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 definition/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.

Achievements

An image is worth a thousand words, so let me quickly show you a screenshot of the rename assistant in action:

Prior to my change, these assistants basically were only useful to the C++ language support. The infrastructure (the controller for showing/hiding the popups) resided in the C++ plugin. But funnily, for example the Python plugin accidently re-used parts of the old C++ language support and hence was able to show these assistants, too. However, whenever we're using the Clang plugin we have to disable the original C++ language support, which suddenly exposed that there's something wrong (i.e. the assistants didn't show up anymore). So, I had a look at it and in the end we've decided that this is useful for all languages and agreed to move this API into kdevplatform.

So, in fact, that change gave us the possibility to base all assistants we have in place on a common interface (called StaticAssistant) and a central place for registering those to the session (via StaticAssistantsManager). The full diff can be seen here: https://git.reviewboard.kde.org/r/118542/ (kdevplatform change).

While this change has basically nothing to do with KDevelop-Clang itself, it still helps to provide a better experience with the Clang plugin enabled. Just let me show you this helpful assistant popup:

or this little guy here:

Note: As you can see, there's a small issue in this screenshot. It doesn't actually show the error text anywhere. It just proposes how to fix it. That's an issue we were already discussing.

What I personally would love to see is to be able to embed widgets in-between the lines in the editor that show the actual error. Working with a bit with Coverity (a static analysis tool) lately, I've found this way of representing errors quite convenient. I've already been in touch with the Kate guys in order to (hopefully) get that implemented at some point.

Wrap-up

So, while these two weeks consisted more of a refactoring work on existing code, it still needed to be done. Any change which cleans up architectural issues in KDevelop land actually makes us really happy.

For the next two weeks I'm focusing on getting all the Code Completion features (see my original blog post for reference) into KDevelop-Clang.

By the way, if you enjoy what we're working on in KDevelop these days, or what people do in KDE in general, please consider donating to a fundraiser helping us to organize a meeting for bringing KDE/KDevelop forward. Your help is greatly appreciated!

Here's the link: http://www.kde.org/fundraisers/randameetings2014/

Thanks!

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!