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

[Flex Ferrum]

Hello

2012/2/1  <eike.ziller at nokia.com>:
>
> On 1 Feb 2012, at 12:53, ext Peter Kuemmel wrote:
>
>>>>
>>>> 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.
>>
>> I'm still skeptical. To often I've heard (at other places)
>> "but we don't like it".

I agree with Peter here. If we have a lot of time and a lot of
motivated developers we could start a contest and choose best solution
then. But, I think, we have neither one nor the other. So some
decisions from top of the head of team/product leader/architect are
needed. In other case we will have nothing but a waste of time. And
this decision is what I asking for.

>>> 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.
>>
>> I don't see the problem here. I only wanna see what the compiler sees.
>> But then you need all the build flags at parse time.
>
> Mind that for some features you actually want *more* than the compiler sees. E.g. when doing "Follow Symbol" your preferred destination is the definition of whatever you follow, not a forward declaration or some declaration in some header. But the definition is in most cases not "seen" by the compiler when it compiles your current unit.

Also I want to notice what IDE code assistant requirements are not
similar to code compiler requirements. Especially for C++ which is
extremely sophisticated and difficult for 'on-the-fly' background
compilation (in comparison with Java, for example).

>>> 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.
>>
>> Yes, I forgot all the Qt macros which are not only "macros".
>> For this stuff the existing parser could be used. But having
>> two parsers running also complicates things.
I think, this task may have another solution. SLOT (and any other
identifier) is just a macros which could be expanded in many different
ways.

Best regards,
Flex Ferrum