We need to provide built-in includes only when we use tweaked headers.
Also let's require Clang resource directory because it has to be
placed on the specific position inside the built-in header paths.
Change-Id: Id581238660c680725201de759216cf33f69f6cc7
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Like you can see in the task numbers this patch is touching many different
areas. So I will only touch the main parts. It is using a clang action
instead of an extra process which will be enabling the handling of
generated files in PCHs. The flags from the project part are now not
anymore transformed in a command line but they are saved in the container
semantically aware so that they can later be merged. Most of this patch is
simply polishing of other patches.
Task-number: QTCREATORBUG-21346
Task-number: QTCREATORBUG-21380
Task-number: QTCREATORBUG-21382
Task-number: QTCREATORBUG-21383
Task-number: QTCREATORBUG-21693
Task-number: QTCREATORBUG-21778
Change-Id: I9b0c02d8149b554254e819448fbc61eeaa5b7494
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
The known cases provide enough flags not to require
toolchain defines.
Change-Id: Ia7e08a90eca6ea9474db40683ac1e63236f8643d
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Clang has MSVC compatible mode which works with MSVC style command line
flags.
When possible use the same flags (-I, -D, -U, etc.) and in other cases
either replace by MSVC analog (for example use /FI instead of -include)
or pass the argument with '/clang:' prefix (requires
https://reviews.llvm.org/D53457).
Change-Id: I95f33bed5dc8d9493895ed8d4359cdd70fc774b8
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Rely on clang to do the "right thing" with them.
Change-Id: I44adf2cd5c61549896da3fc9b7c35c2fb0142060
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
The fix for MSVC2013 undefined clang macros to fix some
internal Qt stuff failing in Qt 5.7.
Now we know exactly which MSVC version is used and can
ignore this fix for newer versions.
Fixes: QTCREATORBUG-16439
Fixes: QTCREATORBUG-21685
Change-Id: Ie2844428c39d72d212198ee2dd6841420a464974
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
According to commit e2e3be09e3 this was
needed for clang 3.8.0 on Windows.
Change-Id: I4f2c2bf31449d9613607e57524c7ff6e4577812a
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
It makes it easier two get different options.
Task-number: QTCREATORBUG-21693
Change-Id: Ibcfa52d8bbbdf971a38fb6102a6b79e037a9cf02
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
After we moved some of the code to HeaderPathFilter we now use it in
CompilerOptionsBuilder.
Task-number: QTCREATORBUG-21693
Change-Id: Iea3569465bbc135d72bd88f9c23026f2ace33aba
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
...for clang code model and clang tools use case.
This means that compiler detection code will see clang now instead of
the toolchain that is configured in the kit. While providing the
toolchain macros worked fine for the general case, it always was
problematic for compiler detection code.
By not providing the toolchain macros we are more close to the real
clang compiler invocation. That is, rely on clang to do the right thing.
Allow to go back to old behavior with QTC_CLANG_USE_TOOLCHAIN_MACROS=1
as this will be useful checking differences for debugging.
Fixes: QTCREATORBUG-19543
Change-Id: I23ffd761d83f35ca1a22269c3ef07a2dc62358bd
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
...for clarity.
No behavior change.
Change-Id: Id0334bc79b97a8ff53b37089e337530c9a01b1d4
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
No behavior change.
Sometimes we use "SkipX, sometimes "UseX". Unify to "UseX" as this is
more natural to read.
Change-Id: Ib08bdb4cde93ed55fdb9c855566b10a3933cae37
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
No behavior change.
* Remove virtual from methods that are not overridden
* Move constant member functions that do no access any members into
source file as static functions
* Remove QLatin1String where possible
* Make variable names a bit more consistent
* Other minor stuff
Change-Id: I34a582d5a468489e11365507b283e9aee157664f
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Boost recognizes a misconfigured compiler in rtti emulation mode
(-fno-rtti) as our libclang command line is special. Even worse, it does
not seem to stop instantiating templates and allocating memory
afterwards.
For the former to fix, we need to rework our command line (in master).
The latter can be work arounded by defining
BOOST_TYPE_INDEX_CTTI_USER_DEFINED_PARSING with a value for gcc/clang.
See also
https://www.boost.org/doc/libs/1_64_0/doc/html/BOOST_TYPE_INDEX_CTTI_USER_DEFINED_PARSING.html
Task-number: QTCREATORBUG-19543
Change-Id: Iddb5be2d1f1966018e5ab535a8f7475fe7911284
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
For the indexing we need all tool chain macros. Originally it was a fix
because the C++ version of the project part and __cplusplus could be
different but now they should be the same. They will be now removed in the
compiler options builder.
Change-Id: I7ae8721a29632473e76ecedb411a6c9001e5e199
Task-number: QTCREATORBUG-21265
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
The only place where Yes is used is the compilation DB, which doesn't
need these defines anyway.
Also add -fPIC for Qt compatibility.
This reduces the compile_commands.json file for Qt Creator from 180M to 33M.
Change-Id: Idd3b363c3a143b1d79f97962c4ff9ee61d7767a4
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Clang include folder should be a part of built-in includes
and always come after user and system includes.
Change-Id: I22961ea3bbb018f41b49f42c6ff7d22eb591ad01
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
C++ include paths should come before Clang include
folder. Therefore parse all options for include/c++/v1,
include/c++/{version}, include/g++ and /usr/local/include.
Task-number: QTCREATORBUG-20231
Change-Id: I22c41f07d241e1e564069bb192d4fe637ff05e87
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
System includes suppress warnings and prevent indexing of unwanted symbols.
Using system includes for all includes outside of the project can be
quite advantageous. The rootProjectDirectory() can be extended to be set
in the project settings. An automatic generation could be possible but
could create an unwanted path which includes files outside of the
perceived project.
Change-Id: Ib9d3158f14f41efe1f6657f962d5c4437bb324b2
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Only libclang has issues with the include directory
search therefore undefining include folders makes sense
only for libclang options builder.
Change-Id: Ie3f62f5f3a89503e6e0ab59e18889e92425c3abc
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
These functions require core plugin so they can't go
to utils library. At the same time to use them in
ProjectExplorer plugin there are not too many choices
where to put them without introducing new dependencies.
Change-Id: I3cccccffaae8ac4bbce924fd809b5423da5dc503
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
We use custom clang executable and it does not make
sense anymore to give a choice of changing it.
Change-Id: Icf86042ac3fcd08c320ef2bbdaabef1102b023b5
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
And add them to other clang code model arguments.
These flags provide architecture for cross-compilation
when ios kit is selected.
Task-number: QTCREATORBUG-19437
Task-number: QTCREATORBUG-19430
Change-Id: I7a485f49d637371bb28b2096086d7d8a4b0c404a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Analyzer has clang path and can generate necessary header paths
to be able to use default options builder.
Change-Id: I9bb1fc158f045f6e099817c5557ee7d9e38416fb
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Affects __FUNCSIG__, __FUNCTION__ and __FUNCDNAME__.
By default Clang can't concatenate strings under those
macros with other strings.
Because of that we need to define them with empty strings
to make clang compile such cases without errors.
Task-number: QTCREATORBUG-19295
Change-Id: I9a3770ebe56b4b8a49ba9982c5a1ba90c8f0b304
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Use the same we use for the built-in code model.
This is useful for conditions of pragmas.
Task-number: QTCREATORBUG-16847
Change-Id: I4c83be46bb2b8a23e4c8f70d98e2b4c9572121ee
Reviewed-by: David Schulz <david.schulz@qt.io>
...for the code model parts and declare 5.0 as the supported version for
the clang static analyzer.
Adapt versions and tests, remove code assuming clang <= 5.0.
LLVM/Clang 5 was released on 07 Sep 2017.
Task-number: QTCREATORBUG-18931
Task-number: QTCREATORBUG-18657
Task-number: QTCREATORBUG-17187
Task-number: QTCREATORBUG-14881
Change-Id: I53b00258ca06a1d2e57f9379dacc54b310687295
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Make build command the same for all builders.
Minimize differences.
Change-Id: I1cfe5071b3afb4944ed178fff1e57d3aee45d8a9
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
The old code model expected the macros as C++ formatted text
("#define Foo 42) but newer targets like the Clang codemodel expect key
value arguments like "-DFoo=42". So instead of parsing the text again and
again we use an abstract data description.
Task-number: QTCREATORBUG-17915
Change-Id: I0179fd13c48a581e91ee79bba9d42d501c26f19f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
...for -std=gnu++0x.
Define the unknown identifier/type "__float128" so at least the headers can be
parsed successfully. Of course this does not help for parsing client code
referencing that identifier, but this should be the less common case.
Task-number: QTCREATORBUG-17126
Change-Id: Id321311713029d8aa77e068b02361d86debfada6
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Same as for the Clang Static Analyzer, so move the implementation into the base
class and use it.
This has gone unnoticed so far because it looks like that the error diagnostic
from the bug report can be extracted with libclang (as shown in the info bar),
but is not printed from libclang or clang.exe itself.
Change-Id: I5b714ba374c5fdefe234faf012a3515e96c9a08c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
...by specifying the word width, as for the Clang Static Analyzer.
This has gone unnoticed so far because it looks like that the error diagnostic
from the bug report can be extracted with libclang (as shown in the info bar),
but is not printed from libclang or clang.exe itself.
Task-number: QTCREATORBUG-17130
Change-Id: Ia7a5ee3825c7211cdf80c2166a9eb454ce48cac1
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
...because it might suggest to append a new line.
Change-Id: I8d5701a1d20c9d94ee528383227a6e3b446b4ff2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Re-produce with:
1) Open qt-essential-includes.pro and configure it with a Qt 5.7.0 MSVC2013
64 Bit Kit.
2) Run the analyzer.
Errors during analyzing occur in winnt.h [1]. This is somehow related to
/D__int32=long that we pass on. Removing it helps.
It looks like there is no reason anymore to pass on the toolchain defines with
clang-3.8 at all. Our unit test projects can be parsed by the analyzer without
them.
Tested with the following kits:
Qt 5.6.0 (mingw39_32)
Qt 5.6.0 (msvc2013)
Qt 5.6.0 (msvc2013_64)
Qt 5.6.0 (msvc2015)
Qt 5.6.0 (msvc2015_64)
Qt 5.7.0 (mingw53_32)
Qt 5.7.0 (msvc2013)
Qt 5.7.0 (msvc2013_64)
Qt 5.7.0 (msvc2015)
Qt 5.7.0 (msvc2015_64)
[1]
In file included from D:\dev\creator\creator-4.1\src\plugins\clangstaticanalyzer\unit-tests\qt-essential-includes\main.cpp:2:
In file included from D:/usr/qt-5.7.0-msvc2013_64/5.7/msvc2013_64/include/QtGui\QtGui:32:
In file included from D:/usr/qt-5.7.0-msvc2013_64/5.7/msvc2013_64/include/QtGui/qopenglcontext.h:60:
In file included from D:/usr/qt-5.7.0-msvc2013_64/5.7/msvc2013_64/include\QtGui/qopengl.h:49:
In file included from D:/usr/qt-5.7.0-msvc2013_64/5.7/msvc2013_64/include\QtCore/qt_windows.h:61:
In file included from C:\Program Files (x86)\Windows Kits\8.1\include\um\windows.h:164:
In file included from C:\Program Files (x86)\Windows Kits\8.1\include\shared\windef.h:24:
In file included from C:\Program Files (x86)\Windows Kits\8.1\include\shared\minwindef.h:182:
C:\Program Files (x86)\Windows Kits\8.1\include\um\winnt.h(3077,1) : error: functions that differ only in their return type cannot be overloaded
__getcallerseflags (
^
D:\dev\llvm\3.8\changingLibClang_install\bin\..\lib\clang\3.8.1\include\intrin.h(68,14) : note: previous declaration is here
unsigned int __getcallerseflags(void);
~~~~~~~~ ^
1 error generated.
Change-Id: I2de8d0393a575f88dd59dfa71fbfb11f2debc158
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
libclang 3.8 seems to be sensitive to file paths separators [1]. On Windows,
this led to not updated document annotations and/or crashes after reparsing.
When passing file paths to libclang, convert to native separators.
When getting file paths from libclang, convert back.
This handles:
* main file path
* file paths of the unsaved files
* -I<DIR> arguments, the resource path (for builtins) and the paths to the
wrapped qt headers
* included header files from libclang
* source locations from libclang
Also, minimize the conversion in SourceLocation to a minimum by making
filePath() lazy.
[1] https://llvm.org/bugs/show_bug.cgi?id=28381
Change-Id: If5866f34a6fdc6b34b16c022d3988e8e6eae2a0a
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For some reason, clang 3.8.0 on Windows does not enable exceptions anymore,
which leads to parse errors in MSVC headers (reported upstream [1]).
With this change, we can finally parse main/mainwindow.cpp of a Qt Widgets
Application for a MSVC2015 Kit and libclang 3.8.0 without any error.
[1] https://llvm.org/bugs/show_bug.cgi?id=27324
Change-Id: I532ad4852a06318baf083d363378bc577b3c4309
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
This applies the following change for the clang code model, too.
commit d13d179524
Clang Static Analyzer: Workaround analyzing MSVC2015 projects with clang 3.8.0 II
Change-Id: Ia229d7e8b24c2e1c0a83d9a53c623ea1f79c4a06
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Infer the version from the _MSC_FULL_VER macro, so it cannot get out of sync
with that.
Adapt the analyzer to do the same.
Based on
commit daf08d8702
Clang Static Analyzer: Workaround analyzing MSVC2015 projects with clang 3.8.0
Change-Id: I9d34abdbe2c83fe271eadd8d051caad43aca6772
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
