Review Request 122161: Fallback to TU url when looking for a cached ParseSession.

[Milian Wolff]

> On April 18, 2015, 4:18 p.m., Milian Wolff wrote:
> > any input on this?
> 
> Sergey Kalinichev 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?

For the first part: I agree, it sucks and we should find a way to improve. But I'll still push this patch as it's an improvement over status quo. Hope you are OK with that.

Regarding the second part of your comment: The pinning is fine - we are using it for a long time without issues.


- Milian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122161/#review79168
-----------------------------------------------------------


On Jan. 20, 2015, 1:09 a.m., Milian Wolff wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122161/
> -----------------------------------------------------------
> 
> (Updated Jan. 20, 2015, 1:09 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdev-clang
> 
> 
> Description
> -------
> 
> This makes code completion in headers work more reliably when they
> are opened after the .cpp file. The other way around its still
> broken though :(
> 
> I wonder whether we should keep the last N TU's alive and use that
> instead of abusing the AST attached to the context...
> 
> 
> Diffs
> -----
> 
>   clangsupport.cpp f4f49b079d52462cfb0d56086780751605a6ab46 
>   codecompletion/model.h 961bdf5cc4a33a9b41cea0cc8c81f0ecfb647b1f 
>   codecompletion/model.cpp 0dcf44cdc801f7c4f330b9137e08f4f54da37b9d 
> 
> Diff: https://git.reviewboard.kde.org/r/122161/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Milian Wolff
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150730/6af10ac6/attachment.html>