GitLab

Be less strict about the default assert message, so it can match also custom
assert messages. Also add an expression that matches the assert_perror() output
of glibc.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

For many years I thought that KDevelop's Stop toolbar menu was broken.
Today after digging into the relevant code and documentation I found out
that one has to press and hold the button for a few seconds for the
submenu to show up.

From the documentation to KActionMenu::setDelayed():
  Remember that if the "main" action (the toolbar button itself) cannot
  be clicked, then you should call setDelayed(false).

This is clearly the case for the Stop menu button and for the Tool Views
menu button (which can be added to the Main Toolbar through Configure
Toolbars dialog): clicking these buttons has no effect.

When a job fails, ThreadWeaver::QObjectDecorator emits both failed() and
done() signals. BackgroundParser::parseComplete() is connected to both.
So when a ParseJob fails, parseComplete() is called twice for the same
job. The most obvious consequence is the too great value of
d->m_doneParseJobs.

Two classes derived from ParseJob - CMakeParseJob and QmlJsParseJob -
call ParseJob::abortJob() when they are aborted, which makes
ParseJob::success() return false and thus causes QObjectDecorator to
emit both signals.

In order to test what happens when the bug is triggered, I edited
CMakeParseJob::run() code to unconditionally call `abortJob(); return;`
after the `if (!package.isEmpty()) {` line. KDevelop seems to handle
this well, but there are lots of relevant debug messages in the log:
kdevplatform.language: m_doneParseJobs larger than m_maxParseJobs: 0 -1
kdevplatform.language: m_doneParseJobs larger than m_maxParseJobs: 1 0

The simple fix is to connect only to the
&ThreadWeaver::QObjectDecorator::done signal. Its documentation states:
"This signal is emitted when the job has been finished (no matter if it
succeeded or not)."

When a user closes a project while its associated CTestFindJob is still
working, the job is not notified and keeps running. After that, when
BackgroundParser eventually parses all documents requested by the job,
the job calls TestController::addTestSuite(). Inside this call the
CTestSuite::project() pointer is dereferenced in
TestView::addTestSuite() => TestView::itemForProject(), which causes a
segmentation fault.

Ideally all associated CTestFindJob-s should be killed just before or
just after a project is closed to revert their no longer useful requests
to BackgroundParser as soon as possible. However, reliably detecting
that the project is no longer open is not straightforward, especially if
the project opening is aborted or the project is closed even before a
CTestFindJob is created. My implementation of such a proper fix is
intertwined with several other CTest-, TestController- and
TestView-related fixes. The combined fix will be so large that it won't
fit into the 5.6 branch. So this commit implements a simple temporary
workaround for the fairly easy to trigger crash: check if the project is
destroyed in CTestFindJob::updateReady() and kill the job if this is the
case.

BUG: 329246
FIXED-IN: 5.6.1

When a user exits KDevelop while a CTestFindJob is still working, the
job is killed from RunController::cleanup() and its KJob parent calls
deleteLater(). But the killed job can be still not destroyed after
DUChain::shutdown() is called, which results in a crash if
CTestFindJob::updateReady() is then invoked via Qt::QueuedConnection.
Note that ~ParseJob() queues calls to CTestFindJob::updateReady(),
which can then be invoked after DUChain::shutdown(), if ParseJob-s are
running when the user exits KDevelop and no event loop is entered in the
time between the ~ParseJob() and DUChain::shutdown() calls (sometimes
the optional QCoreApplication::processEvents() call in
BackgroundParser::waitForIdle() intervenes and prevents the crash).
Core::cleanup() calls backgroundParser()->waitForIdle(), which ensures
that all parse jobs finish, are destroyed and queue "updateReady" calls.

BUG: 423651
FIXED-IN: 5.6.1

KJob::percent(KJob *job, unsigned long percent) signal is public since
https://commits.kde.org/kcoreaddons/c0b312a41f7fcb42ac6251a2d194c7799dfac723
(since KF 5.46).

Simplify JobStatus implementation:
* move slotPercent() from JobStatusPrivate to JobStatus for simplicity;
* remove unused JobStatusPrivate::m_job data member.

ulong => unsigned long in PatchReviewToolView::testJobPercent() because
"ulong" is practically absent from KDevelop source code now.

GIT_SILENT

Let the more efficient loop below queue each set element instead of
searching for each open document in the set gradually emptying it.

When ParseProjectJob's forceUpdate argument is true, closed documents
are parsed with TopDUContext::ForceUpdate feature flag. I think that not
taking into account the forceUpdate argument when parsing open documents
is an omission. Let us parse all documents with the
TopDUContext::ForceUpdate feature flag when forceUpdate is true.

GIT_SILENT

This prevents unnecessary detaching.

GIT_SILENT

ParseProjectJob finishes normally when all its requests are satisfied by
BackgroundParser, in which case there is nothing to revert. Both
ProjectController and RunController abort parsing by killing the job.

Apart from not doing unnecessary work when ParseProjectJob finishes
normally, this commit prevents a hypothetical crash in case the
BackgroundParser's destruction precedes a ParseProjectJob's destruction.

ParseProjectJob::queueFilesToParse() removes the currently open
documents that belong to the project from d->filesToParse. Therefore,
when ParseProjectJob::updateReady() is invoked, the actual number of
files to parse can be greater than d->filesToParse.size().
ParseProjectJob reverts all its requests in the destructor, so the few
unaccounted-for closed documents could remain unparsed.

Only RunController listens to ParseProjectJob::percent() signal (as it
does to any registered job's percent() signal) in order to update total
progress. Background Parser already reports parsing progress, so there
is no need to emit ParseProjectJob::percent(), and so it makes sense to
remove the empty updateProgress() function rather than implement it.

GIT_SILENT

Both the code and the documentation of ParseProjectJob are simplified by
letting ProjectController call its parseAllProjectSources() function.

GIT_SILENT

KJob::finished() signal is guaranteed to be emitted from ~KJob() or
earlier. RunController::finished() slot is connected to this signal and
unregisters the job that emits it.

GIT_SILENT

Remove the now redundant deleting of the ParseProjectJob when its
project is destroyed. ParseProjectJob objects are created in
ProjectController::reparseProject(), which is called when the project is
already fully open. So the project is guaranteed to be closed before it
is destroyed.

A Project is destroyed via deleteLater() after it is closed, so if the
event loop is busy at the time, &IProject::destroyed can be emitted much
later than IProjectController::projectClosing(). With this commit
ParseProjectJob is killed earlier than it was destroyed without the
commit.

Early-return from ParseProjectJob::queueFilesToParse() not only when the
job has been destroyed, but when it has been killed too. The earlier
return not just avoids unnecessary work, but is essential during the
application shutdown: prevents a crash by not accessing IndexedString
after DUChain::shutdown(). Note that KJob::kill() calls deleteLater(),
so a job can be destroyed a long time after it is killed if the event
loop is busy, as it is at shutdown. ParseProjectJob is killed early in
the shutdown process from RunController::cleanup() - before
ProjectController::cleanup(), which would kill it otherwise, and
(importantly to prevent the crash) before DUChain::shutdown().

Remove the shuttingDown() check from ParseProjectJob::start(), because
this member function doesn't access globals on its own. The appropriate
safety checks are now performed in the scheduled
ParseProjectJob::queueFilesToParse().

Don't call deleteLater() in ParseProjectJob::doKill() just before
returning true: rely on auto-delete KJob base class to call it.

BUG: 427387
FIXED-IN: 5.6.1

From KJob::start() documentation:
Warning: Never implement any synchronous workload in this method.
This method should just trigger the job startup, not do any work itself.
It is expected to be non-blocking.

When a user exits KDevelop in the ParseProjectJob::start()'s nested
event loop, RunController may be destroyed in the time between
`job->start();` and `checkState();` statements in
RunController::registerJob(). The result is a segmentation fault in
RunController::checkState().

BUG: 427386
FIXED-IN: 5.6.1

Storing the QPointer-s indefinitely was a small memory leak.

Eliminate a redundant QHash search in
ProjectController::reparseProject().

Fix ProjectController::reparseProject() indentation.

GIT_SILENT

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

If we do no unregister ourselves, KTextEditor will try calling into the
destroyed notes provider.

GIT_SILENT

This function has no observable effects other than imperceptibly slowing
KDevelop down since 57e452e5, where its
debug output was removed in favor of better-formatted debug output in
MIDebugSession::handleDebuggerStateChange(). For some reason this no
longer useful function was not removed in this commit. Now it only
wastes CPU cycles and complicates understanding of the code.

GIT_SILENT

Deleting the QPointers at the beginning of ~CorePrivate() sets them to
nullptr automatically. But even had the pointers remained non-nullptr,
clearing them would be a waste, because the simple CorePrivate object
containing them was destroyed right after the clear() calls.

GIT_SILENT

When a user Execute-Launches an application a second time while the
previously launched instance of this application is still running, the
"Job Already Running" dialog appears with 3 buttons. If a user clicks
the Cancel button, a NativeAppJob kills itself Quietly. This
NativeAppJob belongs to an ExecuteCompositeJob, which is not notified
when a subjob is killed Quietly. So the ExecuteCompositeJob keeps
waiting for it to finish. When this waiting ExecuteCompositeJob is
killed (e.g. via "Stop All" button or on KDevelop exit), it attempts to
kill the subjob it believes is still running, but which in fact is long
since destroyed. This usually causes a segmentation fault.

Aleix Pol fixed a similar crash when the "Kill All Instances" button in
the "Job Already Running" dialog is clicked in
8430d305.

BUG: 399511, 416874
FIXED-IN: 5.6.1

GIT_SILENT

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

GIT_SILENT

(cherry picked from commit 135d20ae + fix)

GIT_SILENT

GIT_SILENT