Review Request 121649: For headers, also use source-file include paths and defines.

[Milian Wolff]

> On Dec. 31, 2014, 7:26 a.m., Olivier Jean de Gaalon wrote:
> > Rather embarassing that I didn't notice this sooner. I came up with a completely different solution: https://git.reviewboard.kde.org/r/121757/  
> > 
> > The advantage of what I have is that it should work for headers that have no buddy but are otherwise used anywhere in the project.
> > 
> > Of course my solution doesn't actually work right now (CMake doesn't build targets, but that needs to be fixed?) so about this:
> > 1. This might useful in addition to the other as a "first guess" before any "target" TUs are found/created
> > 2. I /really/ think it would be better to use the TU of the cpp rather than merging the includes. Is that significantly more work?
> 
> Olivier Jean de Gaalon wrote:
>     What about creating a parse job for the source-buddy and waiting for it?
>     As long as the source environment can beat the header environment it should stick?
> 
> Aleix Pol Gonzalez wrote:
>     (regarding cmake)
>     Well, the headers are extracted from the compile_commands.json file, we just have the headers separately for each .cpp file. In cmake you can have file-specific include directories so doing headers in a target scope doesn't make much sense in cmake (and I guess on others will be the same, e.g. Makefiles).
>     OTOH I have a branch with targets, so they do exist, but it doesn't seem they will get include directories information.
> 
> Olivier Jean de Gaalon wrote:
>     The target item doesn't need include information, it just needs to exist as a parent of the file item. If the item is found to exist inside any target item then it's a target environment.
>     
>     OTOH this is actually just an ugly proxy for what /is/ inside the compile_commands.json file. What kdev-clang actually wants to do is call IBuildSystemManager::isThisATranslationUnit(url), and CMakeManager would respond with isThisUrlInTheJSONData().
>     
>     Of course, that would be CPP-specific, but if we can get a sensible API for that it would be perfect... what about IBuildSystemManager::hasBuilddSystemInfo(url)?
> 
> Sergey Kalinichev wrote:
>     >What about creating a parse job for the source-buddy and waiting for it?
>     >As long as the source environment can beat the header environment it should stick?
>     
>     Yes, it's a good idea. Also I think that it should be implemented in getPotentialBuddies (duchainBuddyFile), as currently it doesn't return anything if the file isn't parsed.

creating parse jobs in a parse job can be done, but one must not wait for it (as you are hogging up a slot of the ThreadWeaver). Rather, you must also resubmit yourself with a lower priority and cancel the parse job - this is what Python and Ruby are doing afaik, when they are missing information.

Triggering a parse job from within getPotentialBuddies doesn't sound like a good idea to me at all. This function has to return quickly, as otherwise the UI is blocked. Also, a parse job is triggered for a file when it is opened anyways. If at all, we could think of sorting buddies after a parse job has finished, but I don't think its worth it.


- Milian


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


On Dec. 23, 2014, 5:28 p.m., Milian Wolff wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121649/
> -----------------------------------------------------------
> 
> (Updated Dec. 23, 2014, 5:28 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdev-clang
> 
> 
> Description
> -------
> 
> We use the existing find-buddy-document architecture to find a
> source file corresponding to the current header file. If we find
> a match that also has a project file, we ask it for its include
> files.
> 
> This fixes an issue, where when editing a header file Clang would
> never find the include paths. The reason is that in e.g. CMake,
> only the .cpp files have include paths, but not the .h files.
> 
> 
> Diffs
> -----
> 
>   clangparsejob.cpp 297b836128c441a7f6aacbac7ec175ca4bf7b8e1 
>   duchain/clangparsingenvironment.cpp 1decc1493eba5b81d18937ce43dd5c24ea6db01f 
> 
> Diff: https://git.reviewboard.kde.org/r/121649/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Milian Wolff
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150103/47ba35f6/attachment.html>