Let's not access the object state after emitting
ClangdFollowSymbol::done(), in case the receiver deletes us.
Can happen in test code.
Change-Id: Ia6c691c0f88b16476da1a6be1cedd106d9da2d53
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@qt.io>
Allow to follow to the symbol definition as well as to the type
definition for the symbol under the cursor position.
Change-Id: I8ff50b33a1e739f81b0832b1b28ffc525e1f7177
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Big files are loaded in chunks inside a QEventLoop. If follow symbol is
triggered via mouse and opens such a big file and the mouse is moved
while loading that file ClangdFollowSymbol got deleted while opening the
file in ClangdClient::followSymbol. Instead of the hard deletion just
cancel that follow symbol operation and make sure done is emitted
afterwards. The handling of that done signal takes care of the deletion
of that follow symbol operation.
Change-Id: Iba4ad6abb541186c2f26506f82fe1bc582818fca
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It is expected that the processor that is created by the provider is not
running.
Fixes: QTCREATORBUG-28769
Change-Id: Icef270c5f9255b97aa04fc3d0ea0cf872787bd24
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
There is a certain amount of time between resetting the processor to
nullptr in ClangdFollowSymbol::VirtualFunctionAssistProcessor::cancel
and the destruction of the ClangdFollowSymbol sentinel. So we also need
to check the processor before calling update.
Task-number: QTCREATORBUG-28769
Change-Id: Idec7c9dd7648285ecf2360c309d9751303f6209c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
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>
