* move existing, usable refactoring tools from C++ to kdevplatform language, make it possible for other language tools to adapt them to their needs (i.e. to get renaming working properly for PHP)

+

** don't show language specific refactoring tools in a different language, i.e. 'move to source' when working on a PHP/Ruby/Python file or such

= Positive Side Effects =

= Positive Side Effects =

Revision as of 11:05, 18 July 2013

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).

NOTE: To make this clear, we _do not want to break existing language plugins_ !!

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.

Problems with integrating Clang into the existing DUChain code

It became apparent that it won't work properly with what we have right now in our language abstraction API in kdevplatformlanguage. On one hand there is the file-based workflow mentioned above, we will find a way to solve or workaround that though. Other problems are:

Tight Coupling between Abstraction and Storage

The classes in the DUChain are so far our abstraction of a language. Things like common types, contexts, declarations, definitions and uses. The big trouble there is that all these classes are tightly coupled to the storage. For Clang e.g. the concept of ranges for a declarations is different (TODO: olijg: please elaborate once more what we want to do in the new clang plugin).

Thus we should refactor our API and decouple the language abstraction from the storage and make it possible for a given language to implement a custom storage layer. This would also be good in future if we have clangd or similar and do not want to duplicate the caching inside KDevelop.