Changeset View
Standalone View
plugins/clang/duchain/clanghelpers.h
| Show First 20 Lines • Show All 98 Lines • ▼ Show 20 Line(s) | |||||
| 99 | * @return True if the given file @a path has the extension of a C++ header file | 99 | * @return True if the given file @a path has the extension of a C++ header file | ||
| 100 | */ | 100 | */ | ||
| 101 | KDEVCLANGPRIVATE_EXPORT bool isHeader(const QString& path); | 101 | KDEVCLANGPRIVATE_EXPORT bool isHeader(const QString& path); | ||
| 102 | 102 | | |||
| 103 | KDEVCLANGPRIVATE_EXPORT QString clangVersion(); | 103 | KDEVCLANGPRIVATE_EXPORT QString clangVersion(); | ||
| 104 | 104 | | |||
| 105 | /** | 105 | /** | ||
| 106 | * @return The path containing Clang built includes (e.g. stddef.h, stdarg.h, cpuid.h) | 106 | * @return The path containing Clang built includes (e.g. stddef.h, stdarg.h, cpuid.h) | ||
| 107 | * The returned path is the env. var KDEV_CLANG_BUILTIN_DIR when set otherwise the path | ||||
| 108 | * to the headers used when kdev-clang was built, possibly updated for upgrades to | ||||
mwolff: the code isn't actually only checking for minor upgrades, or? | |||||
No, the code just tries to generate the path corresponding to the current version from what it has. In practice this will correspond to minor upgrades because the typical path has 2 version components and we only correct one: /usr/lib/llvm-6.0/lib/clang/6.0.1/include We could correct the first one too but it seems very unlikely that the code will ever get to be executed after major upgrades because libclang itself will no longer be in /usr/lib/llvm-6.0/lib (but under /usr/lib/llvm-X.y or, theoretically, /usr/lib/llvm-6.y). But yeah, if someone decides to install LLVM to a location that does NOT contain the major version number then my code should handle any upgrade or even downgrade, as long as the plugin still loads against the new libclang. rjvbb: No, the code just tries to generate the path corresponding to the current version from what it… | |||||
| 109 | * the library (e.g. 7.0.0 -> 7.0.1). | ||||
| 110 | * Returns an empty string if none of the checked locations contain the file cpuid.h . | ||||
| 107 | * | 111 | * | ||
| 108 | * Also see: https://clang.llvm.org/docs/FAQ.html | 112 | * Also see: https://clang.llvm.org/docs/FAQ.html | ||
| 109 | */ | 113 | */ | ||
| 110 | KDEVCLANGPRIVATE_EXPORT QString clangBuiltinIncludePath(); | 114 | KDEVCLANGPRIVATE_EXPORT QString clangBuiltinIncludePath(); | ||
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 mwolff: we should always use the same header, everytime. i.e. hardcode "cpuid" in this function and… | |||||
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? rjvbb: That works too, of course. Is `cpuid.h` the most appropriate (least likely to be… | |||||
| 111 | 115 | | |||
| 116 | /** | ||||
| 117 | * @return True if the given @a path is a valid clang builtin directory. | ||||
| 118 | */ | ||||
| 119 | KDEVCLANGPRIVATE_EXPORT bool isValidClangBuiltingIncludePath(const QString& path); | ||||
| 120 | | ||||
| 112 | } | 121 | } | ||
| 113 | 122 | | |||
| 114 | #endif //CLANGHELPERS_H | 123 | #endif //CLANGHELPERS_H | ||
the code isn't actually only checking for minor upgrades, or?