We used the same code in different but don't shared it. From a bug fixing
perspective it's actually not that smart.
Change-Id: Iaaffc883229e259ff77f95b5cf0a8f0d8b5117df
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
We probably should add a message box for this in the master version.
Change-Id: Icc01eeb258445c361e7c6227e6bd768b9d16d350
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reproduce with:
1. Create a new class named Foo with the wizard.
2. Close foo.h
3. In foo.cpp, add some class member function.
4. In foo.cpp, trigger the refactoring action "Add public Declaration"
for the just defined member function. As a result, foo.h will be
opened.
==> While the declaration was added, the header file is not yet
reparsed with the new content - this can be verified by setting
a custom color for "Function".
In this use case, the refactoring action opens the editor and
immediately modifies the document (RefactoringFile::apply).
Fix by sending the document content along for the very first
RegisterTranslationUnitForEditorMessage if the document was already
modified.
Change-Id: If20615a45b72dd0bef87e1870e403d0b277bc5d6
Reviewed-by: David Schulz <david.schulz@qt.io>
Feeding libclang with unsaved files (e.g. in-memory generated ui_*.h)
that do not exist on disk leads to regeneration of the preamble on every
parse/reparse/completion and thus renders the clang code model useless.
We could check the existence in the file system for every unsaved file
just before every parse/reparse/completion. Obviously this does not
scale (e.g. qtcreator.pro generates about 200 unsaves files) and would
also slow down the responsiveness of the completion, especially for the
dot-to-arrow correction case.
We could also set up a file system watcher. However, implementing the
"file got created" case is not trivial because QFileSystemWatcher does
not support it out of the box.
Instead, set up a custom include directory and create empty files in it
that represent the unsaved files and pass that include directory to
libclang as the last one. While this fixes the performance problems, it
also comes with at least two problems:
* Because ui_*.h files are "relocated" to the same directory, two or
more "foo.ui" in the same session will be problematic.
* Because of the custom include directory, problems might arise for
projects that include the ui_*.h as "some/relative/path/ui_foo.h"
instead of "ui_foo.h". This should be the less common case.
Task-number: QTCREATORBUG-17245
Change-Id: I6e40e87c3ef095086eb22c972dd8c1a6459a8245
Reviewed-by: Marco Bubke <marco.bubke@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>
Ignore the include path for intrinsics coming from the toolchain. The
clang static analyzer comes with its own intrinsics and does not cope
well with intrinsics from other clang versions.
Move the relevant implementation from LibClangOptionsBuilder into the
base class so that ClangStaticAnalyzer profits from this, too.
Task-number: QTCREATORBUG-17102
Change-Id: Id9a28ddebb889c862939332dce888a80b3bb7e63
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Clang expects these to lie in "../lib/clang" relative to the clang
executable.
Change-Id: I216860876591dca1fd728e4b1e79b4b07c965620
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@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>
As for the analyzer, this makes us independent of the default triple and will
most likely reduce the maintenance - e.g. the target implies certain internal
command line arguments, we will profit from added ones.
This fixes parsing of mingw headers with the clang code model.
Change-Id: I722b981125a80fac5f62a7af40a83ecdd7bbf811
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Prevent libclang from using any builtin includes paths or any standard system
directories. The project manager provides us all the necessary information.
Task-number: QTCREATORBUG-15345
Change-Id: I70e2dafea8d049a9b7a32b24ce2d4ce3dac2cd3b
Reviewed-by: Marco Bubke <marco.bubke@theqtcompany.com>
This can be used to experiment with clang options that e.g. affect
diagnostics.
Changes take effect on editor re-open.
Change-Id: Ie46d0ff085a3700a748dbcf4b94b93b0bf9c4642
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com>
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
...since it assumes a project part != 0 and does not participate in
ownership.
Change-Id: Ia9c1eca52776990576a2dac61e9144234b04c59c
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
If an editor is changing all translation units independent of their project
part they must be updated too. So we introduce a new message to update all
translation units with the same file path.
Change-Id: I70d0ea2bbca9fa880111ff7219573e54f3277026
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
It's actually tricky because the standard says that zero arguments should
be not possible in variadic macros but certain compilers support it and we
using it in the logging framework.
Change-Id: Ib9e1832748e8c57f149dfcfefead9618fd5e51f4
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
Fix use-after-free for the following case:
1. Open an editor
2. Trigger a long processing completion
(e.g. simulate with QThread::msleep in
CppCompletionAssistInterface::getCppSpecifics)
3. ...and immediately close the editor (e.g. with Ctrl+W)
4. Wait until it crashes.
The completion thread relied on the BuiltinEditorDocumentParser object,
which is deleted once the editor is closed. Fixed by sharing the
ownership of that object between the *EditorDocumentProcessor and the
completion assist interface.
This case came up when doing tests for the bug report below.
Task-number: QTCREATORBUG-14991
Change-Id: I0b009229e68fc6b7838740858cdc41a32403fe6f
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
Diagnostics are now moved to the clang backend process. Fixits are
supported too.
Change-Id: I20faacf466bbf78dec479220c3d7b336a47bc453
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
exactMatch() is declared const, but is actually not. Replace with
QRegularExpression.
Change-Id: Ib9d9c091de1cd81d81671c19a76cada8777ff287
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
On OS X the clang versioning is different.
This completes
775661fafb
Clang: Ignore clang include directories from the toolchain
Task-number: QTCREATORBUG-14856
Change-Id: Ib93ce9fcf18a3c8693f9f2af8075eeef8b93fa32
Reviewed-by: Marco Bubke <marco.bubke@theqtcompany.com>
More precisely, free us from specific Q_MOC_RUN/QT_NO_META_MACROS code
paths in QtCore/qobjectdefs.h.
In order to track signals and slots we provided custom definitions of
e.g. "Q_SIGNAL" by including qt5-qobjectdefs-injected.h with "-include".
We also had to ensure that those macros were not overwritten by Qt's
qobjectdefs.h, which we did by defining QT_NO_META_MACROS. However, this
came with a cost: we needed to replicate all the other macro definitions
in the Q_MOC_RUN/QT_NO_META_MACROS code path, e.g. Q_INTERFACES. This
bound us to specific versions of qobjectdefs.h and occasionally we had
to adapt (see change 4eafa2e02b).
The new approach wraps Qt's qobjectdefs.h with the help of
"include_next". In the wrapper header, we only redefine what is
necessary.
The "include_next" directive is originally a GNU extension. Clang seems
to support it unconditionally, as [1] implicitly states.
[1] http://clang.llvm.org/docs/LanguageExtensions.html#include-file-checking-macros
Change-Id: Ic1a263f94b178349cb32bfdbb074ad5e6e0761ee
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
...makes the high-level function build() less noisy.
Change-Id: Ib09fba315845a604166489fd400d0be14e16fc23
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
File paths are not unique since e.g. each qbs group in a file is mapped
to a project part.
Change-Id: I7df3f224dd23046b869f2588b8a34eb26cfc0b1a
Reviewed-by: Marco Bubke <marco.bubke@theqtcompany.com>
Making CompilerOptionsBuilder to use the toolchain from the project part
simplifies its public API, but following the code paths initiated by
ClangCodeModel and ClangStaticAnalyzer gets harder, so better enable the
separation of those by making CompilerOptionsBuilder a base class.
Change-Id: I0a6bb3f8323ba09b88135a7f9d1ef967331a8ff0
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
This makes us independent of libclang crashes for completion.
Re-parsing for highlighting still happens in the Qt Creator process.
Run in verbose mode:
qtc.clangcodemodel.ipc=true
Run tests:
-test "ClangCodeModel"
Task-number: QTCREATORBUG-14108
Task-number: QTCREATORBUG-12819
Change-Id: Id3e95bd2afdb6508bbd1d35fddc69534a909b905
Reviewed-by: Marco Bubke <marco.bubke@theqtcompany.com>
Opening a main.cpp of a Qt Widget Application project that is configured
with a GCC toolchain leads to errors [1] like
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/ia32intrin.h:41:10: \
error: use of undeclared identifier '__builtin_ia32_bsrsi'
due to a wrong determination of the clang directory with intrinsics. The
directory was determined as
$${LLVM_LIBDIR}/clang/$${LLVM_VERSION}/include
whereas $LLVM_VERSION was extracted as e.g. "3.5" from 'llvm-config
--version' instead of "3.5.0".
The path of clang intrinsics dir shipped with Qt Creator (as package)
does also match this version scheme:
$QTC_INSTALL_DIR/share/qtcreator/cplusplus/clang/3.4.2/include
[1] Visible with qtc.clangcodemodel.verboserun=true
Change-Id: I1061912eef437a9889987e638915d2fabe208011
Reviewed-by: hjk <hjk@theqtcompany.com>
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
