[Qt-creator] Future of Qt Creator's C++ parsing

[eike.ziller at nokia.com]

Hi,
since this seems to interest quite a few people, and there were (very valid) questions on what we actually plan to do regarding the C++ model and clang, we finally sat together (yes, real life, in a real room :D ), cooking up a plan.

Summary of the result, details follow below:

1) First priority short term is to make Qt Creator's current code model handle the new C++11 features gracefully (help needed, see long story!)
2) Middle term (i.e. 2012/13) we want a hybrid solution where clang is used for code completion and semantic highlighting, and the current code model is used for mostly everything else
3) Long term we would prefer using clang for everything code related in Qt Creator, but when both clang and Qt Creator might be ready for that, we don't know

So, fixes for Qt Creator's current code model are not in vain, they are actually appreciated and necessary, but it's important that fixes keep the speed and flexibility intact :)

Long story with explanation:

1) First priority short term is to make Qt Creator's currently code model handle the new C++11 features gracefully

The new features are used more and more, even in standard libraries especially on Linux, so we need to make sure that Qt Creator at least doesn't bail out with errors and fails to parse code that uses these features (and the code that uses that code and so on). Qt Creator doesn't need to really *understand* these features, but must still be able to parse the rest.
We would be very happy to receive help for that task, which is also easy to chop up into parts.

2) Middle term (i.e. 2012/13) we want a hybrid solution where clang is used for code completion and semantic highlighting, and the current code model is used for mostly everything else

That would use clang for the cases where the user "wants to see what the compiler sees" (i.e. be as accurate as possible). It is also where clang excels compared to the current code model (which is more optimized for speed and intricate guesses for the cases where the user doesn't actually want to see what the compiler sees). This separation avoids the necessity for things like persisting the code model and using precompiled headers, because clang is fast enough for this task as is. The heavy task of indexing the whole project's code would be still done as it is done now. The two models could also pass information to each other on request, e.g. when the user does a "follow symbol", the semantic information from clang could be used to find a better match in the global index.
Tasks to make that happen: Take the wip/clang branch and throw the clang indexing and related experiments out, keep the clang based code completion and semantic highlighter. Preferably make the code completion handler and semantic highlighter exchangable between current code model and clang, so people can easily check out the clang based stuff but have a fall back until we are sure it's good enough. We also need to figure out how to make it as easy as possible to build the clang part which currently depends on clang's development branch.

3) Long term we would prefer using clang for everything code related in Qt Creator, but when both clang and Qt Creator might be ready for that, we don't know

The optimal solution would be to use clang for everything code related, instead of maintaining two different models. At the moment that's just not realistic though.

Happy hacking,
-- 
Eike Ziller
Principal Software Engineer

Nokia, Qt Development Frameworks

Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori