... to take a function returning a FilePath as base.
Implementation is (not) yet changed.
Change-Id: I624efab35cf38631c816b630be5296bdf696899e
Reviewed-by: David Schulz <david.schulz@qt.io>
This scenario is used for testing against regression in StringTable.
If the scenario went OK, the creator finishes and doesn't crash.
Later, this scenario will be invoked from additional test, so that
the second instance of creator will run and the test will
check if the subprocess finished OK. So it's going to be combined
with autotests in the follow up patch.
In order to test it, run creator with the following command line:
"-settingspath ~/.config -scenario TestStringTable". Make sure,
that you point settingspath to creator settings which have
proper kit with a toolchain and Qt setup.
The regression may be tested by restoring the
src/plugins/cpptools/stringtable.cpp to the parent of
f4ab1279fd and by applying on top of it
this patch (simple conflict may need to be resolved). In this case
running this scenario ends up with a crash (so, it confirms this test
fails on the old code form before the fix).
Change-Id: Icbb56233495047fd68bfb605fcd088f352a16323
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
... so we can re-use the "follow symbol" test cases with clangd.
Call Creator like this (clangd needs to be version 12 or later):
$ QTC_CLANGD=<path to clangd> qtcreator -test
'CppEditor,*Follow*,*Switch*' -test 'ClangCodeModel,*dummy*'
During testing, some invalid code in the test cases was uncovered and
fixed.
Change-Id: I9dc650fdba2a27600e6a550420ee873f6fb31d23
Reviewed-by: David Schulz <david.schulz@qt.io>
.... when following virtual function calls.
This brings us up to par with the built-in code model.
We do lose the icons, but they are of very little use in this context.
Change-Id: I29b27d538e7277d06a5af7acee07bddb6eb94c98
Reviewed-by: David Schulz <david.schulz@qt.io>
They may differ in a containerized setup.
Change-Id: Ib7e60fdd69f56e8e22bad3dfbc246e7de2fe9cd4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Still some missing bits as some QString members had different meanings
depending on their context.
Change-Id: Ib48eab54498974a26bbd5123cbffeefee5f7e79c
Reviewed-by: hjk <hjk@qt.io>
It may happen that the old task was canceled and still running
while the new task was started. Later, when the d'tor is called
both old and new tasks may still be running. Before we waited only
for the new task to be finished in d'tor. Now we are waiting
for all tasks to be finished.
Amends: 7fb592fe0c
Task-number: QTCREATORBUG-25709
Change-Id: Id4b44cd36ee03aa45472b15d8fbb25a2cab77e92
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The ClangCodeModel's RefactoringEngine implements all operations now and
thus does not have to be excluded anywhere.
Change-Id: Ie3c2107d02e13463fc85f1a5319454db2c45915f
Reviewed-by: David Schulz <david.schulz@qt.io>
Some compilers have outdated defaults; e.g. the current Apple clang on
my test machine sets __cplusplus to 199711L (whereas earlier releases
already used 201402L ...).
Amends 9c3420120e.
Change-Id: I8708b41f6d616ca0f1b73f72473f4612e463bff6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Note that we do not use the LSP rename functionality. We do "manual"
renaming the same way as in the built-in code model, but based on the
references found by clangd.
Change-Id: Ifa5597efe5c89c8f9204a4f5323bc755544696cf
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Schulz <david.schulz@qt.io>
Otherwise, locator results for template specializations appear to be
duplicates when they really are not.
Change-Id: Ief20c876ec6e7d41a7d4c9dc8e35bcf1e7e60ced
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Do not wait for the previous update to finish before starting the next
update.
Amends: 6d7e5eb8d1
Change-Id: Ic8d43b56949cbf024832afc85e54a31db29b11ac
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This makes more sense than using the clang defaults.
Task-number: QTCREATORBUG-25562
Change-Id: I796d29bb4e81e5e257efea998dcab037efd8a717
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
If the user has enabled clangd (default is off), we start up one instance
per project when it is opened/changed (including build config switches),
and trigger background indexing.
So far, the index is used to provide results for locators and "Find
Usages".
Per-document functionality such as semantic highlighting and completion
is still provided by libclang.
Change-Id: I12532fca1b9c6278baab560e7238cba6189cde9f
Reviewed-by: David Schulz <david.schulz@qt.io>
The possible issue with the current implementation is that
in theory many possible GC() are being executed in parallel.
In this case just one of them is really working and others
are waiting on the locked mutex (first line of the GC()
method). In such a scenario when a call
to StringTablePrivate::insert() is being executed from one
more thread, it may happen that the working GC() thread
is stopped (since m_stopGCRequested.fetchAndStoreAcquire(true)
was executed from insert()) and later the mutex lock may be
granted to the other awaiting GC() thread instead to the
thread which executes insert() method. In this unlikely
scenario the GC() thread won't be canceled and the lock
inside the insert() method may be locked for considerable
amount of time, what is not desired.
The goal of this patch is to resolve the possible issue above
and to simplify the code by eliminating the m_stopGCRequested
variable and make use of QFuture.cancel() / QFuture.isCanceled()
API instead. In addition, since we control now only one
possible thread that executes the GC(), there is no need for
future synchonizer anymore.
GC() function can't be run in parallel in different threads,
as the whole body of GC() is protected with mutex. This means
that whenever a new scheduled call to GC() is being executed,
this new call waits on the mentioned mutex at the beginning of GC().
So, instead of protecting the whole body of GC() with a mutex,
we ensure that the old call to GC() is already finished (if not,
we also cancel the old call) while preparing an asynchronous
call to start a new GC() from inside startGC() method.
Whenever we are calling the insert() method, we still protect the access
to m_strings with a mutex (as insert() is designed to be called
from different threads in parallel). Just after locking the mutex
we are canceling any possible ongoing call to GC(). After canceling
the GC() call, we are sure that no new call to GC() will be executed
until we unlock the mutex, so it's safe now to modify the m_string
data.
Change-Id: If72d0a6f98fb414c6c63117bc9baa667d17e1ffe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
We need to take into account that the ">>" in constructs such as
std::vector<std::pair<int, int>> is only one token on the clang side.
Change-Id: I90f002ca56f236032f6d39c338593a2ff7590061
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Schulz <david.schulz@qt.io>
Makes TestTreeItem programming language agnostic.
By moving the "query" methods to CppTools, the cohesion within these
methods is improved, i.e. information crosses the AutoTest <-> CppTools
border fewer times. Furthermore, it allows the CppTools plugin to see
how its data is being used, allowing it to optimize its queries
behind the scenes.
Change-Id: I0a60140abaca1193d500605dfa2812b4d937d94c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The issue is that when a GC() function is being executed
in a separate thread, the main thread may delete
the StringTable (on shutdown) in the same time. The destructor of
StringTable didn't check in any way that the other
thread is still executing GC() method.
In order to fix it we employ runAsync method, returning
the handle to the running task. We store the handle
in futureSynchronizer, and in destructor of StringTablePrivate
we safely wait for all futures to be finished.
Fixes: QTCREATORBUG-25417
Change-Id: I0039d6041276c521c221e8dfc3894e84e47b82a2
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's unlikely that the user wants to change files that are not part of
the currently loaded projects, so opt-in is the right approach for
those.
Fixes: QTCREATORBUG-8561
Change-Id: I1812a3e64de66828ac07dea7bbb63acdb4dd40d8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This is shown as tool tips in the location options, and if any platform
supports this also as tool tips on the menu actions of the locator input
field.
Change-Id: I8b439e45e6097a16a5f932d25d4e5d3e9bddb6ad
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Some wrong tr calls / missing tr functions.
Some places where we need to bring lupdate to the right track with
regard to namespace resolution.
Change-Id: Idf552054a34e24d9671db68c816bf37f4d403dbc
Reviewed-by: hjk <hjk@qt.io>
Don't use recursive mutex in CppLocatorData class,
as this is more expensive to construct than simple
QMutex. Refactor the code so that every call to
flushPendingDocument() is done with already locked
m_pendingDocumentsMutex. This eliminates the need
for recursive mutex.
Remove unused allIndexItems() method.
Change-Id: Ic7cb45bc3301d83768e69ee52f84ae159cb731a5
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
SearchResultItem defaults to the standard application font,
we need to tell it to use the text editor font explicitly,
like the specialized addResult method did that was removed.
Amends d3deefc3a4
Fixes: QTCREATORBUG-25396
Change-Id: Id8d41d93c96fbfd6d993568a37d42509da452665
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
For instance, if the user types "template<", then the next operator> in
the source code will be temporarily classified as the closing angle
bracket for that template. Therefore, we have to clear out any previous
information of that kind.
Change-Id: Ib6d64415b2f6294661e2b8ec48cbaea5893d8fd0
Reviewed-by: David Schulz <david.schulz@qt.io>
... to "warnings from build system".
It seems appropriate to respect the project settings by default.
Change-Id: I397c252409a012f4663f3752c5c097fa0e658da4
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
That is, make SearchResultItem the one data type for adding search
results.
This will allow us to add additional properties to search results
without adding more and more parameters to a bunch of functions.
Change-Id: Ic2740477ae47449cee75caa2525727fe2b460f91
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Not a use case anymore, and if it were, we'd do it using built-in
capabilities.
Change-Id: I4c588ad7fb282530880210cb4c5795677074b1e0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
