Qt Creator - clang code model doesn't find types, even though code compiles

[GarryJ]

Qt Creator 4.7.1 is driving me nuts today - the clang code model is throwing up false positives for undeclared types, even though the code compiles just:

Did a brief search and there have been similar issues , but it looks like they're just plain bugs. Are there any configuration settings which have an influence, or is this just a bug to wait to get fixed? Is it possible to disable the analyzer if it keeps being a dick?

[GarryJ]

New development: running Qt Creator from the command line, I see a whole bunch of Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted errors. Will take a look around the issue tracker to see if there are any candidates for introducing a regression...

[aha_1980]

Hi @GarryJ,

from my experience I can tell that Clang can get picky if it does not understand some construct (in your code or in some included) or it can't find one of your header files.

Sometimes it helped me to clear the .pro.user together with the build folder and to open the project again.

For some of my C projects I needed to clean up all includes so they don't generate errors and now (with Creator 4.8-beta1) it seems I reached a good point (let's cross fingers).

If you still encounter problems in a file after the clean reloading, investigate the headers it includes to see if there is some Clang problem you can solve on your side.

Good luck!

[GarryJ]

Thanks for the input!

Still trying to track down the real source; the issue crops up any time <string> is included, with the following annotation:

So, clang doesn't seem to find the closing brace for namespace std _GLIBCXX_VISIBILITY(default) in <ostream>. Normally this would indicate a missing closing brace in some other include file, but in this case I'll be damned if I can find it. And, if it were the case, the code wouldn't compile with GCC, which it does.

If it's not that, I'm guessing that there's some kind of mismatch between the GCC header files being used by clang to generate the code model, and those which I'm actually using. I would've assumed that Qt Creator feeds clang with the right data (i.e. the sysroot for the kit), but maybe not.

[GarryJ]

Looks like it may be a regression: https://bugreports.qt.io/browse/QTCREATORBUG-16660.

[ziller]

You have a yellow warning icon in the editor's toolbar. If you click this, you'll see details on issues that the code model had when parsing included files. Maybe this gives some hints on what is wrong.

[GarryJ]

@ziller Thanks for that, I feel like a chump for not noticing this earlier.

After delving into the code model warnings, it looks very similar to this bug: https://bugreports.qt.io/browse/QTCREATORBUG-19667. Seems like getting the code model to play nice when you're cross-compiling is a bit finicky..

[GarryJ]

In my particular case (Qt Creator 4.7.1, CMake 3.8, GCC 7.3, targeting x86_64-poky-linux, via Yocto :-|), the fix was all too simple:

CMake has a variable called CMAKE_SYSROOT which passes the sysroot path to the compiler. When compiling with our GCC toolchain, it wasn't necessary to set this variable, as the sysroot was hard-boiled into the cross-compiled GCC itself.

When opening a CMake project in Qt Creator, Qt Creator detect several features of the imported kit, but not the sysroot - this has to be entered manually in the kit settings.

To get the code model working properly, CMAKE_SYSROOT must be set, and the sysroot must be entered correctly in the kit settings.

[rsacchettini]

@GarryJ said in Qt Creator - clang code model doesn't find types, even though code compiles:

CMAKE_SYSROOT

Thanks I had the same issue, had the CMAKE_SYSROOT configured ok, toolchain working ok at the CMAKE level, but did not have the right QtCreator Kit setting "Sysroot:" on the right directory.

Technically speaking, it was my fault, like no one is supposed to ignore the law, but just the same without clear indication, everyone needs a lawyer to know the law.
Validating the sysroot setting when configuring the kit is not that easy until you make that mistake.
Should be documented with a bit more warnings about the role of it and how to ensure this is working and valid...

Thanks a lot anyway !

[Old Wolf]

I had this same issue using QtCreator 4.11.2 in MSYS2, but trying to use the MSYS2 GCC (package msys/gcc) instead of the default mingw64/gcc.

If I select (auto-detected) MSYS2 GCC as the compiler in the kit configuration, then the inline compilation messages indicate that stdio.h cannot be found, and under Tools > C++ > Inspect C++ Code Model, the field "BuiltinPath", which is supposed to have the path to system includes, shows as blank.

I partially fixed this, after reading this thread, by setting the kit's sysroot to be the path of my MSYS2 installation.

Setting sysroot to F:\Prog\msys64 caused the Clang Code Model's BuiltinPath to be detected correctly as F:/Prog/msys64/usr/include .

This causes #include <stdio.h> to be handled correctly, but #include <stddef.h> still fails. Because that file is in F:\Prog\msys64\usr\lib\gcc\x86_64-pc-msys\9.3.0\include .

As a workaround I added F:\Prog\msys64\usr\lib\gcc\x86_64-pc-msys\9.3.0\ to the INCLUDEPATH for Qmake, or the includes list for external project. But this is not really a desirable solution.

Furthermore, setting this sysroot causes debugging with GDB to fail as it can no longer find C:\Windows\system32 for DLLs that the binary depends on. So in the end I reverted the sysroot to blank and also added F:\Prog\msys64\usr\include to INCLUDEPATH.

Is there any way to manually configure what shows up under BuiltinPath so I can put the right paths there? Should it be considered a bug that qtcreator does not correctly set BuiltinPath without manual intervention?