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

[Jonathan S. Shapiro]

On Wed, Feb 1, 2012 at 5:01 AM, <eike.ziller at nokia.com> wrote:

>
> On 1 Feb 2012, at 12:53, ext Peter Kuemmel wrote:
> > 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.


[Eike: I'm not a Qt guru, but I've worked on IDEs and compilers before]

Eike is right. There are several ways that an IDE needs more/different
information than a compiler:

1. The IDE needs to work on code that doesn't compile. This is why, for
example, the C/C++ infrastructure in Eclipse performs its parse by building
(possibly wrong) tree fragments in "bottom up" form. When code is being
edited, it is normal and expected that the Eclipse parser will fail to get
a complete parse. It is nonetheless able to provide very useful information
for browsing.

2. Compilers are designed to recognize the difference between "stuff that
gets analyzed when I handle this unit of compilation", "stuff that gets
checked by the linker", and "stuff that just doesn't get checked". There
are cases where an IDE needs to extract cross-file information [where
available]. For example: we usually don't want to browse to an ELF weak
symbol that is an alias for an actual procedure. We want to find the target
procedure instead.

3. Browsers need better understanding of the preprocessor. The Qt macros
are one example, but also think about all of the issues in global
search/replace when symbol splicing is done by a preprocessor macro.

4. It isn't true that we just want to see what the compiler sees. There is
often code that is ifdef'd out, but is relevant for some closely related
scenario. This is actually a slippery slope. We may not want to see code
for another target, but we *may* want to  be able to browse to debug code
even when "ifdef debug" is turned off. How far to go here is a judgement
call, and it's a tricky one. Note further that this *requires* something
like the bottom-up parse approach used in Eclipse, which clang does not
give us.


I have no opinion pro or con about clang, except to note that tuning a
compiler front end for performance is something that takes a while. GCC
went through two or three major versions before the Bison-based parser got
thrown out in favor of a hand-written parser for speed reasons. CLang has
to go through the same evolution over time, and it isn't as far along in
that regard.

shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20120201/fbf5c25c/attachment.html>