[Qt-creator] wip clang status

[Peter Kuemmel]

-------- Original-Nachricht --------
> Datum: Sat, 3 Dec 2011 15:43:29 +0100
> Von: "André Pönitz" <andre.poenitz at mathematik.tu-chemnitz.de>
> An: "Peter Kümmel" <syntheticpp at gmx.net>
> CC: qt-creator at qt-project.org
> Betreff: Re: [Qt-creator] wip clang status

> On Sat, Dec 03, 2011 at 12:57:36PM +0100, Peter Kümmel wrote:
> > On 03.12.2011 12:16, leandro.melo at nokia.com wrote:
> > > Hi,
> > >
> > >> Is wip/clang in an usable state?
> > >
> > > I wouldn't consider it in an usable state yet. There are parts that
> > > are working well, but many things are still quite incomplete (like
> > > code navigation as you noticed). In addition, there are still a lot
> > > of features that rely on the "old" parser, which should eventually
> > > be adapted/rewritten.
> > 
> > Code navigation works now.
> > 
> > But your reply sounds like it is still not clear if clang has a future
> > in qtcreator.
> 
> It is not clear.
> 
> It is clear that a clang based parser will be _much_ slower than the
> existing one.  Even with a lot of caching etc. this will still be
> intrusive for the user projects, like the need to use precompiled
> headers.

Yes, its's much slower but in times of idling cores it isn't such a problem. 

> 
> And then it's hard to have things like connect() parsed as "use" of a
> signal or a slot etc. 

Here I would patch clang. 

> 
> So a clang based parser would have an impact on usability, and it's not
> clear whether the "better" understanding of the code would outweigh
> that, especially since even a 100% perfect C++ parser does not help in
> #ifdef blocks.

Doesn't the clang function pre-process the code? Or do you talk
about the disabled parts of a macro block?

> 
> There might even be room for a hybrid solution, i.e. use a combination
> of both, but that starts with a memory penalty, and maintaining two
> parsers might not feasible either.
> 

On the long run I assume the clang direction is the better one. But maybe 
is is worth to have the old parser as fallback or as option if the clang
parser is really too slow.

And having a 100% C++ model build-in opens the door for much more features, like code-rules, code-analysis, ...

Peter