GitLab

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"

This makes ItemRepositoryRegistry loose the dependency on
ISession::Lock, which wasn't really needed to begin with.

Simplifies unit tests, cleans up architecture.

File was still locked by the QTemporaryFile object and the subsequent
Document::saveAs() failed and causes a popup.

Scripty meanwhile has been instructed to skip such files

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"

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"

Unit test is still not fixed though.

Problem:
```
22:30:32 FAIL!  : KDevelop::TestKdevFormatSource::testNoCommands()
Compared values are not the same
22:30:32    Actual   (initTest(formatFileData)): 0
22:30:32    Expected (true)                    : 1
22:30:32 C:\CI\workspace\KDevelop kdevelop stable-kf5-qt5
WindowsMSVCQt5.9\kdevplatform\util\tests\test_kdevformatsource.cpp(53) :
failure location
22:30:32 QFATAL : KDevelop::TestKdevFormatSource::testNoCommands()
ASSERT failure in QTest::fetchData(): "Test data requested, but no
testdata available.", file
C:\CM-Build\MSVCQt5.9\build\libs\qt5\qtbase\work\qtbase-opensource-src-5.9.1\src\testlib\qtestcase.cpp,
line 1105
```

Summary:
VcsOverlayProxyModel::data() calls ProjectController::changesModel()
which currently is a non-const method which might create an instance
of ProjectChangesModel which in turn triggers some KJobs.

Avoid that by instantiating ProjectChangesModel() immediately during
startup. I don't think that has a real performance impact.

BUG: 384162
FIXED-IN: 5.2.1

Reviewers: apol

Reviewed By: apol

Subscribers: mwolff, dfaure, brauch, apol, kdevelop-devel

Differential Revision: https://phabricator.kde.org/D8852

This ensures that for each release, we clear the item repository.
In the past, we had various issues related to old caches -- this change
should avold that, since we no longer need to remember to bump the
ITEMREPOSITORY_VERSION variable on each release.

Changing ITEMREPOSITORY_VERSION is still possible to force a clear even
if KDEVELOP_VERSION is untouched.

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"

When we import a cmake project folder and that contains nested
CMake projects, we ended up showing the same target multiple times,
since the CMake server output will reference the same targets for
the parent project and then again for the nested project(s).

Ensure the targets are only added once to fix this issue.

BUG: 387095

When KDevelop starts up, we will quite early receive the background
parse requests for the last opened documents in the session. These
then often get added to the background parser (BP) before the project
controller is fully initialized - i.e. before any project was even
tried to be loaded. This means the m_loadingProjects safety guard in
the BP does not kick in and we create parse jobs with "broken"
environments, i.e. missing include paths and defines for kdev-clang.
If, and only if, the document has been modified since the last time
KDevelop was started, we would actually parse the document with the
broken environment, leading to flickering when we show the result
for the broken environment before reparsing it after the project gets
opened with the correct environment. Additionally, this of course
adds useless load to the startup phase and frees up resources better
spent elsewhere at this point.

Note that since the project controller itself delays its
initialization via the eventloop, we have to add a new signal to
ensure we resume the background parser only once we have tried to
open all previous projects, such that the m_loadingProjects safety
guard in the BP can kick in properly.

This is not fully integration-tested, as it's pretty complicated
to do so. Rather, we only test the individual parts automatically.
The full integration test was done manually via:

- create kdev session and open some project
- open a file in that project
- close session with file still opened
- touch file on disk to force reload on next startup
- restart kdevelop session
- check visually and via CLI output whether file gets reparsed twice,
  i.e. before the project was loaded and afterwards

This patch series ensures it only gets reparsed once after the project
finished importing.

Subscribers: kdevelop-devel

Differential Revision: https://phabricator.kde.org/D8907

Suspending only stopped the timer and suspended the thread weaver
queue. This is not enough: When startTimer is called the next time,
e.g. via ::addDocument, it would still trigger a call of
parseDocumentsInternal and eventually the creation of a parse job.
That one wouldn't be able to start working, as the queue is suspended.
But for clang parse jobs, it would already try to look for the
foreground parse environment (i.e. include paths and such). A future
patch will suspend the background parser while the core is being
initialized, which ensures that we won't create parse jobs with
broken environments at startup.

Subscribers: kdevelop-devel

Differential Revision: https://phabricator.kde.org/D8906

Subscribers: kdevelop-devel

Differential Revision: https://phabricator.kde.org/D8905

Summary:
Don't assert the validity of the IndexedString (while calling toUrl
on it), in the JobPlan's updateReady callback while the core is
shutting down. This is potentially getting called when the database
has been shutdown, leaving an empty/invalid string behind.

Subscribers: kdevelop-devel

Differential Revision: https://phabricator.kde.org/D8904

Subscribers: kdevelop-devel

Differential Revision: https://phabricator.kde.org/D8903

Subscribers: kdevelop-devel

Differential Revision: https://phabricator.kde.org/D8902

Summary: These should only ever be called by the Core during init/shutdown

Subscribers: kdevelop-devel

Differential Revision: https://phabricator.kde.org/D8901