D17858: clang: Also detect Clang builtin dirs at runtime on Unix

[René J.V. Bertin]

rjvbb marked 3 inline comments as done.
rjvbb added a comment.


  Should I de-obfuscate and remove that lambda expression too while we're at it? Its body could be the body of `clangBuiltinIncludePath()` itself, AFAICT.

INLINE COMMENTS

> mwolff wrote in clanghelpers.h:115
> we should always use the same header, everytime. i.e. hardcode "cpuid" in this function and remove the argument here, and also hardcode it in the error message

That works too, of course. Is `cpuid.h` the most appropriate (least likely to be removed/renamed), or would e.g. stddef.h or stdarg.h be safer choices?

> mwolff wrote in parsesession.cpp:277
> it cannot be empty at this point, it would indicate serious brokenness (since the plugin would be loaded even though it shouldn't be). remove this if and revert back to the old code

There is 1 situation where this might actually occur: when you install a clang update and don't think of restarting KDevelop.

You'll probably still get errors from the plugin, but at least they'd point to the actual problem, instead of suggesting a weird bug in the code.

I can't seem to trigger it though (moving the builtin dir should have the same effect); how does one trigger the creation of a new ParseSessionData instance?

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D17858

To: rjvbb, #kdevelop, flherne, mwolff
Cc: arrowd, mwolff, flherne, kdevelop-devel, glebaccon, hase, antismap, iodelay, geetamc, Pilzschaf, akshaydeo, surgenight
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20190109/71a7d4ad/attachment.html>