Each call of CppModelManager::updateSourceFiles detaches the current
snapshot.
The extra compilers where set up and triggered individually, and
resulted in individual updateSourceFiles calls with the single result
file of the extra compiler. For Qt Creator this would lead to 200
calls in quick succession after project load, potentially leading to a
freeze of multiple seconds.
Instead of updating the result files of the extra compilers individually
after project load, integrate the update into the regular project source
file update. So we end up with only a single call of updateSourceFiles.
For this the project updater needs to trigger the extra compilers, and
wait for all to finish as well as the regular project part update,
before
triggering the parser.
Task-number: QTCREATORBUG-25783
Change-Id: I34f6df0fc0f96bcb42ee65019bee39cf49176c1f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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>
The code was pushing an additional QFutureInterface through the whole
chain of functions, which was used for canceling. But since it was never
started (and never finished, and never used for reporting results),
calling waitForFinshed on it never had any effect with Qt5 and locks up
with Qt6.
Instead of using a separate QFutureInterface, use the actual QFuture
that is available and intended for it.
Fixes: QTCREATORBUG-24902
Change-Id: I5a49bcecc9cf70fbffa93aee4293004f9369df58
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In Qt 6 implicit conversion between QFuture and other types
is forbidden. Make it explicit instead.
See ff0ba7e2d7b91fd5809cb314935a1ca1a436f6c9.
Change-Id: Ie42e6b9b5047ba5eeec9f63fd03179e73f95314d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... by letting callers pass in a generator function.
This takes some load off the UI thread for larger projects.
For now only used by the QbsProjectManager, which can provide a thread-
safe generator function due to the project data existing in "value"
form.
Task-number: QTCREATORBUG-18533
Change-Id: I525dea36a4c4079bd1bd5a4fff844617547d56f1
Reviewed-by: hjk <hjk@qt.io>
Especially in the light of the language server, the generic project is
currently the project one can use for language servers that require a
"project workspace".
Makes it possibly to run Qt Creator with
"-noload CppTools" if you still want to use generic
projects with some other language.
Change-Id: Ib9059289a2db4c44c0c1060a02fcdafacb885fbd
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Used for updating project parts, so move it near RawProjectPart.
Change-Id: I77aeffbdbfb3d2ec0de600f61dcf7fbb7a355a98
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Also remove the signal CppProjectUpdater::projectInfoUpdated() which is
now unused.
Change-Id: I65afe8f96cd8175edaf8ccb6e5067e4f9cd8d99f
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
${AnyProject}::updateCppCodeModel() did two potentially not that cheap
operations in the ui thread:
(1) Querying the MimeDatabase for the mime type for the source files of
the project. In 99.9% of the cases no files need to be read for
this as the file extension will resolve the type. The expensiveness
comes from the sheer number of files that can occur.
(2) Calling compilers with the "(sub)project's compiler command line"
to determine the macros. While the caches avoid redundant calls,
the number of the unique compiler calls makes this still a
ui-freezing experience.
These two operations are moved into a worker thread. For this, the
expensive compiler calls are encapsulated in thread safe lambdas
("runners") in order to keep the "mutexed" data minimal. The original
API calls of the toolchains are implemented in terms of the runners.
While adapting the project managers, remove also the calls to
setProjectLanguage(). These are redundant because all of the project
managers already set a proper value in the constructor. Also, currently
there is no need (client) to report back detection of C sources in
project parts. This also keeps CppProjectUpdater simple.
There is still room for improvement:
* Run the compiler calls in parallel instead of sequence.
* Ensure that the mime type for a file is determined exactly once.
Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
