Fallback to TU url when looking for a cached ParseSession.

[Sergey Kalinichev]

I've just noticed that we pass CXTranslationUnit_PrecompiledPreamble
flag, so that Clang can internally use PCH for preamble. Why can't we
build the precompiled preamble manually then, without including
project files? And doesn't it mean that reparse and code-completion
performance for cpp files will drop in that case, as Clang has to
reparse project files with all their includes?

Still I don't understand why we can't create another TU for a header
file with includes/defines used by the cpp file? What difference does
it make? If it does make a difference can't we maybe create another TU
for a header solely for code-completion?

--
Sergey

On 4/20/15, Olivier J. G. <olivier.jg at gmail.com> wrote:
> 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
>