Fallback to TU url when looking for a cached ParseSession.

[Milian Wolff]

Hey Sergey,

On Tuesday 21 April 2015 11:29:54 Sergey Kalinichev wrote:
> 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?

I don't quite understand you - can you rephrase your question? The 
CXTranslationUnit_PrecompiledPreamble option will create a temporary PCH for a 
.cpp that includes all the .h of that .cpp (afaik). You want to remove this 
option and instead manually build a PCH of all included files /except/ of the 
project headers? That will be quite some work, as you'll:

- first parse the full TU
- iterate over all imports and exclude project files
- create a file only including these files
- reparse that one to create a PCH
- then future files can leverage this PCH

note that this might be problematic when files depend on defines or similar 
that are set in project files
also, one would like to share these PCHs for other TUs if possible

Generally, I'd rather have a good GUI and code to generate (and update!) PCHs 
of system headers from within KDevelop. Afaik this is also provided by 
QtCreator and leads to significant speedups there. Imagine being able to put 
all of STL or all of STL + Qt into a PCH and then just using that for 
projects!

> 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?

A header is not a TU, it does not have all the required information like 
include paths and defines. The latter might even be set from other files 
included before in the TU. And doing something solely for code-completion 
means we will duplicate work: when the header changed, we'll need to reparse 
the TU sooner or later anyways. Also, the results will not be correct anymore.

Bye

> 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

-- 
Milian Wolff
mail at milianw.de
http://milianw.de