Uploaded image for project: 'Qt Creator'
  1. Qt Creator
  2. QTCREATORBUG-16660

Clang code model reports false errors with cmake

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Not Evaluated
    • Resolution: Fixed
    • Affects Version/s: Qt Creator 4.0.3
    • Fix Version/s: None
    • Component/s: C/C++/Obj-C++ Support
    • Labels:
      None
    • Environment:

      Description

      Clang code model reports false errors when using standard library in cmake projects.

      For example, in this code:

      #include <iostream>
      
      int main()
      {
          std::cout << 0 << "\n";
          return 0;
      }
      

      clang code model will mark std::cout line with errors like:

      5:15: error: use of overloaded operator '<<' is ambiguous (with operand types 'ostream' (aka 'basic_ostream<char>') and 'int')
      ostream:508:5: note: candidate function [with _Traits = std::char_traits<char>]
      ostream:502:5: note: candidate function [with _CharT = char, _Traits = std::char_traits<char>]
      (and so on...)
      

      Code compiles without any error with both GCC and Clang. It looks as if Clang code model didn't saw any overloaded operator<< functions. It doesn't complain for char* and char types. Interestingly this doesn't seem to happen when qmake or Qbs build system is selected.

      Steps to reproduce:

      1. enable Clang code model in plugins,
      2. restart Qt Creator to apply changes,
      3. create a new "Plain C++ Application" project, select cmake as build system,
      4. modify default code to print an int instead of default cstring. Changing "hello world" string to 0 will suffice,
      5. save the file,
      6. wait for Clang code model to highlight any errors.

      Expected result:

      No errors from Clang code model.
      Warnings about unused argv and argc variables.

      Actual result:

      False errors from Clang code model (code compiles without any problems).
      Warnings about unused argv and argc variables.

      Analysis:

      It seems that this issue is related to both cmake and to "<configuration>" defines available in C++ code model in "Working Copy" tab. Some time ago this problem was visible only if GCC kit was selected in qtcreator for compilation. When clang was set then there was no "errors" like that. I looked for differences that might cause that and analysed ostream headers to see why they might be "incomplete". By trial and error I came to conclusion that this is due to value of __cplusplus define. Setting different kit cause it to have different values. I've determined that if I force 199711L value (one from clang) then clang code model stops reportiong those false errors:

      #define __cplusplus 199711L
      #include <iostream>
      
      int main()
      {
          std::cout << 0 << "\n";
          return 0;
      }
      

      Seems to work just fine. However thats just an inacceptable workaround.

      With recent versions of Clang, qtcreator, cmake etc. switching kits no longer works for some reason even though Clang kit still defines __cplusplus as 199711L. Sadly I don't remember versions when this occured.

      I've attached small code (like the one above) with simple CMakeLists.txt file that allows to reproduce the issue.

      Note that this doesn't apply only to iostream. When I create an std::string, clang code model will complain about incomplete type std::string (header is included of course).

      I've checked that on clean OS install: issue is visible as well.

        Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

            Assignee:
            kosjar Nikolai Kosjar
            Reporter:
            hicks Michał Buczeluk
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Gerrit Reviews

                There are no open Gerrit changes