KDevelop/ClangRoadmap

From KDE Community Wiki
Revision as of 10:18, 18 July 2013 by Milianw (talk | contribs) (Created page with "This document is supposed to lay out the roadmap towards proper Clang integration into KDevelop. This is about Clang as a backend for our C++ language support, not related to ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This document is supposed to lay out the roadmap towards proper Clang integration into KDevelop. This is about Clang as a backend for our C++ language support, not related to using Clang as a compiler for your project (you can already do that).

Why Clang

Maintenance

Our existing C++ language plugin might work reasonably well for C++03 code. But for more complicated features from C++11 (e.g. variadic templates, constexpr, ...) are not yet supported. Due to lack of time and manpower, it is an open question when, if ever, we come around to implementing this. Furthermore one can note that the C++ standards committee picked up speed. With C++14 concepts e.g. will become a technical preview which again will be lots of work to implement properly.

Using Clang as a backend will give us kickass support of C++ "for free".

Static Analysis

Using an IDE like KDevelop for writing C++ should reduce the amount of time you need to compile your code, just to see what errors you made. Clang comes with excellent error reporting tools. These we will then be able to show directly inside the editor.

Refactoring

KDevelop so far comes with only very rudimentary support for refactoring. The clang community is very actively writing new tools though which we can then integrate.

Why Not Clang

File-based Workflow

So far, KDevelop uses a file-based workflow which is different from what compilers do: They work on translation units and a given file is not necessarily compiling standalone. We will need to figure out how to support this, such that one can still open a file in KDevelop without first loading a project and still getting _some_ language support. Also, working on headers or new files in a project should "work" just like it does now.

Performance

It is left to be seen how clang works in terms of performance. So far it looks "OK", especially since one should be able to write code that leverages multiple CPU cores much better. We will probably have to look into precompiled headers though. Potentially we will also have to spearhead the effort behind the clangd idea, where one could share information acquired for the IDE with the compiler and other external tools.

API/ABI

The C++ API of clang is still not stable. Probably the AST part will never become stable. It is left to be seen how this will be problematic. As long as source compatibility is given, or at least source changes are minimal, I think this will work out OK. It might mean requiring new versions of Clang and it will definitely mean that we need to get in contact with the Clang community. We need to be aware of changes they make and make them aware of what we are using it for.