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

[Nicolai Hähnle]

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



duchain/clangparsingenvironment.cpp
<https://git.reviewboard.kde.org/r/121649/#comment50513>

    This is an O(n^2) algorithm, isn't it? I'm working on a project where we have ~30 custom include paths; 30^2 isn't gigantic, but still - if there's a simple alternative that is not O(n^2) (and I admit that I don't see one yet), then that should be taken.


- Nicolai Hähnle


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/20141223/7fd2b0ba/attachment.html>