[Qt-creator] QtCreator C++ code parser and clang integration status

[André Pönitz]

On Tue, Jan 31, 2012 at 10:57:58PM +0100, Peter Kümmel wrote:
> > If you don't contribute to either route - even at the risk that someone
> > on the "other" route is faster or better - your impact on the final
> > outcome might be limited... ;-)
> 
> I didn't know there is a contest :)

It's a contest. The better solution wins. And "better" in the strictly
practical sense. If one approach is implemented, and the other not,
the implemented one is better.
 
> > [Apart from that I currently think that the solution in the end will be
> > some kind of a hybrid, so the risk to waste time is very low]
> 
> Anyway, it would really help to become more clear about the roadmap.

There is no roadmap beyond the usual "when there is time and interest,
someone might work on it".

> Couldn't we/you make any decision what will happen in concrete?

There is no base for any kind of "decision" as there is not enough data
yet to quantify cost or utility of either approach. Of course one could
invent a few numbers, or roll dice to come to _some_ decision, but I
honestly don't see any reason for doing so.

> Because clang is so(too) slow when it is used to parse the complete
> code when a project is opened, we use it only for special files.
> Only opened files will be parsed by clang, only then the context
> and code navigation should be "perfect"?

The assumption that a clang based code model would be perfect "because
it is a real compiler" comes up often, but is wrong.  There will always
be "unclean" #ifdef'd blocks, bunches of .cpp that only compile when
#include'd in a defined order, or a specific namespace, headers that are
included multiple times with different #defines set, etc.
Any non-trivial code base has examples for things like that.

clang won't solve that kind of problems. clang would bring in the
remaining bits of C++, clang would bring Objective C and C++. But it
wouldn't come for free. On the Creator side there suddenly _needs_ to be
a way to persist code models with all the ugly problems that brings
regarding storage, synchronisation and housekeeping. There's suddenly an
"upstream" and the need to explain why stuff in SLOT(...) should be
handled as function signature, and not the string literal that the
compiler sees. The user suddenly has to use precompiled headers and
his CPU is suddenly really busy.

To cut it short: There's a whole lot of cost associated with the clang
approach beyond the pure performance issue, and I am personally very
sceptical that this would be a net gain. On the other hand, it might
just work. But we'll only know after someone actually implemented it...

Andre'