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)."