Fallback to TU url when looking for a cached ParseSession.

[Milian Wolff]

Hey all,

replying inline below, also to Sergeys original post from reviewboard that 
Olivier kindly cited.

On Monday 20 April 2015 16:53:40 Olivier J. G. 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.

The code to pick the right sessionData (i.e. the right URL) is in ClangIndex 
and reused by my patch. Or what do you mean exactly?

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

The "issue" that I want to fix is the following:

- you have a .cpp open and parse it. The .cpp URL/DUContext gets the Clang AST 
attached
- now you open the corresponding .h file. Without my patch, you won't get any 
code completion now, even though all required information is available but 
code completion looks for the AST attached to the .h file, not the .cpp file 
(fixed by my patch).

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

Sergey, is the above with or without my patch? Do you have an example file 
pair for me to play with? What do you change to trigger the behavior?

Also, there are some projects out there where the .h depends on stuff that 
gets included before from the .cpp file (webkit e.g.). To get proper code 
completion in the .h file one thus needs to have the .cpp information 
available as well.

> ---------------------------------------------

Now to Olivier's part:

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

I agree 100%, see above also.

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

This is a good idea, but who knows when we will have the required code in 
Clang.

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

Personally, I see other issues that make code completion pretty slow and 
unusable (e.g. it offers me to implement thousands of functions that are 
defined in system headers but clang never sees the definitions).

So maybe we can fix other things to improve the situation...

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