This way the base class can manage the lifetime of the interface object
and it doesn't need to be done in each implementation of perform.
Change-Id: Ie1ce742e31b688a337533ee6c57d376146e25ace
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Define the run type of the processor by its implementation instead of a
enum value of the provider. The execution of a processor inside the
assist now follows a unified procedure.
Change-Id: Ibe9fab324c6072e77702c2663946d7a9f562a085
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The complete memory management in the code assistant needs an overhaul.
For now just delete or at least track the assist interface with scoped
pointers.
Fixes: QTCREATORBUG-28408
Change-Id: I0bd4cfaa36a660b6fd5bb467af3b13414ed76e63
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace.
Task-number: QTBUG-99313
Change-Id: I88edd91395849574436299b8badda21bb93bea39
Reviewed-by: hjk <hjk@qt.io>
Making use of LSP's "Go To Type Definition".
Just the backend for now, UI to follow.
Change-Id: Id73b2cf701eab03913477f6d4d3093e257e80dbd
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Since we are now requiring macOS 10.14 we can remove our local
implementation of optional and use std::optional for macOS too.
Change-Id: I2bd018261b68da64f7f031a812045dd7784697e1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Make sure emitDone() is atomic with running the callback, so in case the
latter starts an event loop of its own, we won't be overtaken by
incoming signals, deleting the object from under us.
Task-number: QTCREATORBUG-27910
Change-Id: I586d7609974662bf391b12041f416aaa2a973ecb
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Before this change the done() signal was emitted 3 times
in a row. The reason was that first one was coming
synchonously from handleGotoDefinitionResult(), while
2 others were scheluded with queued connections.
So, the handler for done() signal was called 3 times.
The first invocation calls deleteLater() and clears
the pointer, while the object is still alive.
Before the request to delete later gets dispatched,
the 2 remaining done() emissions are dispatched,
so the handler is still called 2 times.
One possible solution would be to disconnect from
done() signal inside a handler. However, the done()
signal shouldn't be called many times, so this fix
ensures the done() is emitted only once.
This fixes the following prinouts:
"QCoreApplication::postEvent: Unexpected null receiver"
issued twice on every follow symbol interaction.
Amends 650bc260c6
Change-Id: I9b440a80386aca3462eda323e51a76696e53fa6b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It can happen under certain circumstances (high system load, overworked
clangd, ...) that "follow symbol" requests get replied to very late,
with the user having manually navigated to the target document in the
mean time or started doing something else entirely. In such a situation,
it would be disruptive if we were to jump to a symbol suddenly, stealing
the cursor from the unsuspecting user.
We now prevent this by aborting the "follow symbol" procedure if the
user does something else with the document.
Fixes: QTCREATORBUG-20878
Change-Id: Iea52db661e8ba634951b18654a94e4b90580f001
Reviewed-by: David Schulz <david.schulz@qt.io>
