I get the error Problem in Semantic analysis Cannot initialize object parameter of type 'QBoxLayout' with an expression of type 'QVBoxLayout' for the line "boxLayout->setAlignment(Qt::AlignTop);" (and many other examples) in my code. I'm using cmake if that makes any difference. Source code is located at https://github.com/z3ntu/RazerGenie, if needed. Maybe related, but 5.2 also doesn't find "iostream" anymore: Problem in Semantic analysis 'iostream' file not found
Reportedly, changing from "clang" to "gcc" in the "compiler for path" combo box in the project settings fixes the issue. Anybody knows why?
Can you give more information? What compilers do you have installed? Which ones is KDevelop using (cf. the project settings combo box that Sven references).
Compare also this thread: https://forum.kde.org/viewtopic.php?f=218&t=141820
The person in the forum confirms that setting compiler to "gcc" fixes it. Which is weird, since I have now heard reports of both setting it from gcc to clang, as well as from clang to gcc fixing this issue. Maybe it depends on the combination of versions of libclang and gcc? It seems weird, either way.
I just had this problem as well (or a similar one), with subclasses of Qt classes (e.g. QObject subclasses) were not recognized as such. I dug into it and it seems that on my system (Ubuntu 16.04 with KDE neon unstable), /usr/bin/clang is clang 3.8. The compiler autodetection then uses this and ends up with putting /usr/lib/llvm-3.8/lib/clang/3.8.0/include into the include path in CMakeParseJob. My guess is that these headers clash with libclang-5.0 and prevent proper parsing of the Qt headers. My solution was to add a manual compiler in KDevelop settings pointing to "clang-5.0" and choose that in the project settings under language support. Maybe the compiler autodetection should search for "clang-XY" first when linked against libclang-XY? Or, alternatively, include directories given to libclang could be sanitized, preventing version mismatches.
I have now raised this on the clang-dev mailing list to get some feedback from other users of libclang. Hopefully there is some trick we aren't aware of...
Can those of you who are affected by this issue try this patch please: https://phabricator.kde.org/D12331 Does it help? Does it break in new ways?
Git commit c791359763cd862f93ad9f91fa628d20e1e630f2 by Milian Wolff. Committed on 27/04/2018 at 10:24. Pushed by mwolff into branch 'master'. Always use the clang builtin headers for the libclang version we use Summary: When we try to parse GCC builtin headers, or headers from other clang versions, we can easily end up with dozens of parse errors that eventually reach the error limit. In such cases, kdev-clang becomes completely unusable. To prevent this from happening, we filter out the compiler include path for the builtin headers. This is done using a simple heuristic by looking for the varargs.h header. For my system, this is only available in these three folders: /usr/lib/clang/6.0.0/include/varargs.h /usr/lib/gcc/arm-none-eabi/7.3.0/include/varargs.h /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/varargs.h All of them are folders for the compiler builtin headers. So now we always exclude these folders, and instead find the include path for the folder containing the builtin headers matching the libclang version we link against. This is required, since libclang does not find any builtin headers on its own, cf. [1]. [1]: https://clang.llvm.org/docs/LibTooling.html#libtooling-builtin-includes In the end, this gives us a seemingly well working GCC emulation layer without the previous pitfalls. The macro compatibility header kept breaking, and we never had any support for different clang versions. Subscribers: kdevelop-devel Differential Revision: https://phabricator.kde.org/D12331 M +6 -1 plugins/clang/CMakeLists.txt D +0 -1463 plugins/clang/duchain/gcc_compat.h M +4 -16 plugins/clang/duchain/parsesession.cpp A +22 -0 plugins/clang/libclang_include_path.h.cmake M +4 -1 plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.cpp https://commits.kde.org/kdevelop/c791359763cd862f93ad9f91fa628d20e1e630f2
I still get this issue. I'm running KDevelop 5.2.4 on Manjaro KDE. And as commented before, changing from Clang to GCC fixes the problem.
It looks as though the fix didn't go into the stable branch. This should be fixed from 5.3.0-beta1.