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



  • 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:

    0_1539357039921_virtual_serial_port_base.cpp (components-libutilities-src @ smartcom) [feature-ADV-1591] - Qt Creator_022.png

    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?



  • 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...


  • Qt Champions 2018

    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!



  • 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:

    0_1539592826705_Menu_024.png

    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.



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



  • 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.



  • @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..



  • 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.


Log in to reply