Fallback to TU url when looking for a cached ParseSession.

[Olivier J. G.]

On Mon, Apr 20, 2015 at 9:44 AM, Sergey Kalinichev <
kalinichev.so.0 at gmail.com> wrote:
--------------------------------------------
 I don't know. It feels wrong that code-completion is now responsible for
such tasks as: which sessionData to choose for code-completion, especially
when we
 already have a very similar code in the ClangParseJob which should select
the right session data for header files.
    So, for me it looks like the bug is somewhere within the ClangParseJob
which doesn't attach the right parse session data to header files... Or
maybe I simply
 don't understand how this thing suppose to work.

    Also I begin to wonder whether this pin TU feature is the right thing.
Because now re-parsing and code-completion in header files takes
significantly more time then in cpp files. E.g. when code-completion
invoked in a header file with a TU for cpp file, code completion for me can
easily take 4-6 (and even more!) seconds. This is how much time it takes
Clang to reparse the document (so there is probably nothing we can do about
it). I believe it happens because when you edit a header file with TU for a
cpp file, Clang can't use internally precompiled PCH to make a quick
reparse (as it does when you edit a cpp file), so it has to reparse some
(the currently edited and maybe even all other) header files and the cpp
file, which takes significantly more time, than simply reparsing a header
file.
    So I'm actually thinking about switching back to the old approach: each
opened in editor file has it's own TU. What do you think?
---------------------------------------------

To be clear: TU pinning is the /only/ correct way to handle creation of
DUContexts. Only the translation units defined by the build system can be
considered correct for any purpose (including code completion). If you
don't keep track of a header's translation units you have no correct view
of that header. This is the single most important problem with C++, and
we've been fighting it since before KDevelop 4.0 was released.

This affects duchain correctness, refactoring (esp. renaming), environment,
etc.

Obviously we have a real issue, as your analysis (breaks the precompiled
preamble) is very likely correct. The /correct/ solution is to fix clang to
allow us to ensure that project files do not get included in the
precompiled preamble. I just don't have the time to be hacking on Clang (or
KDevelop) now, but it's obvious that's where the biggest wins for KDevelop
will come from at this point -- for this and other issues.

With that said, in the likely case that no one is going to fix this
correctly in Clang, making code completion not horribly slow in headers is
obviously important. Whether it's more important than having correct TUs is
a judgement call to be made by those writing the code... just keep in mind
the consequences of each decision.

-Olivier JG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150420/2935a2e7/attachment.html>