GitLab

Summary: When doing the benchmark test on windows. Make sure that we use windows paths. Otherwise the test will fail (in debug builds) in an assert in util/path.cpp

Test Plan: Run the test in a Windows debug build environment. Before patch it fails. After patch is applied it succeeds. Run test on Linux and see that test stil completes

Reviewers: #kdevelop, kfunk

Reviewed By: #kdevelop, kfunk

Subscribers: kdevelop-devel

Tags: #kdevelop

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

Failed with:
/usr/include/libkomparediff2/kompare.h:93:32: error: 'QString::QString(const char*)' is private within this context
    QString _localDestination = "",
                                ^~

(cherry picked from commit b03b30c2)

Summary:
This test depends on your system configuration and the presence of many headers.
Running the test in debug mode with address sanitizer can make it slow, so 5 seconds might not be enough.
In fact, it takes around ~10seconds here. Plus the test also fails on the CI because of the short timeout.

Increasing it to 60secs solves the problem for me.

Reviewers: #kdevelop, apol

Reviewed By: #kdevelop, apol

Subscribers: kdevelop-devel

Tags: #kdevelop

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

Summary:
BUG: 401075
FIXED-IN: 5.3.1

Test Plan:
Remove entries from kdeveloprc, paths are auto.detected both with
clazy 1.4 and clazy 1.3 (well, its simulated doc path).

Reviewers: #kdevelop, kfunk

Reviewed By: #kdevelop, kfunk

Subscribers: kfunk, kdevelop-devel

Tags: #kdevelop

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

Summary:
The Clazy plugin relies on the project providing a buildsystem manager
to query for the toplevel build directory. If a project has no such manager,
showing the Clazy plugin config pages in the project settings has no
purpose.
As a session might contain different projects, some with a buildsystem
manager, some without, simply disabling the Clazy plugin might not be
wanted for the projects with a buildsystem manager.
So we need to have some condition whether to show some plugins per-project
config pages or not.
For a start, motivated by the crash with the Clazy plugin which has a
hard assumption of project->buildSystemManager() being != nullptr,
this patch adds to the code to collect the config pages for the project
settings dialog some special code which makes use of the plugin metadata
to skip plugins which require a org.kdevelop.IBuildSystemManager, if
there is no buildsystem manager available for the project.
As well adds the (so far missing) entry
X-KDevelop-IRequired: [org.kdevelop.IBuildSystemManager]
to the metadata.

BUG: 400769

Test Plan:
Clazy config is no longer shown in the project settings dialog if the
project is used with the generic project manager.

Reviewers: #kdevelop, apol

Reviewed By: #kdevelop, apol

Subscribers: kfunk, kdevelop-devel

Tags: #kdevelop

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

(cherry picked from commit 2e82c3e5)

Summary:
The bundled libfontconfig seems to cause problems when the target system uses
a newer font config format. See discussion here:
  https://mail.kde.org/pipermail/kdevelop/2018-October/019726.html

It seems to be a common problem (as seen in bug reports of other AppImage
projects).

It's also blacklisted in linuxdeployqt:
  https://github.com/AppImage/AppImages/blob/master/excludelist

For me locally, after the change I also have the exact same font appearance
as with native applications. Before the patch the fonts did use my
anti-aliasing settings iiuc. Before the patch, running the AppImage resulted
in lots of warnings:

```
Fontconfig warning: line 5: unknown element "its:rules"
Fontconfig warning: line 6: unknown element "its:translateRule"
Fontconfig warning: line 9: unknown element "description"
Fontconfig warning: "/etc/fonts/conf.d/10-hinting-slight.conf", line 4: unknown element "its:rules"
Fontconfig warning: "/etc/fonts/conf.d/10-hinting-slight.conf", line 5: unknown element "its:translateRule"
Fontconfig warning: "/etc/fonts/conf.d/10-hinting-slight.conf", line 8: unknown element "description"
...
```

... these warnings are now gone.

Thanks for the analysis by Friedrich.

Actually easy to test using the new AppImage format. Just do:

```
./KDevelop-5.3.0-x86_64.AppImage --appimage-extract
cd squashfs-root
./AppRun # to check appearance before
rm rm usr/lib/libfontconfig.so.1
./AppRun # to check appearance after rm'ing the lib
```

Reviewers: brauch, kossebau, cullmann

Reviewed By: cullmann

Subscribers: cullmann, kdevelop-devel

Tags: #kdevelop

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

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"

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"

Summary:
Since cmake 3.0 cmake also supports --help-policy-list, matching the
general --help* pattern. The KDevelop cmake documentation plugin
already has an entry for "Policies", just it is not filled with any
content.
This patch extends the content indexing by also including the policy.
For cmake < 3.0 the process CMakeCommandsContents::processOutput will
catch the failing call by the exit code, and things are as before.

Reviewers: #kdevelop, apol

Reviewed By: #kdevelop, apol

Subscribers: kdevelop-devel

Tags: #kdevelop

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

(cherry picked from commit 2f0f3da7)

Summary:
FunctionDefinition::definition always looks for FunctionDefinition based on the DeclarationId, but we don't need to do that if we already have a FunctionDefinition.
This could cause problems if we have multiple (same) definitions.

Test Plan:
- create a small cmake (or whatever) project with 3 targets
-- util1.c / util2.c / util3.c (same content):

```
#include <stdio.h>
#include <stdlib.h>

void configure()
{
    printf("do stuff in %s\n", __FILE__);
}

int main(int argc, char *argv[])
{
    configure();
    puts("Hello, UTIL!");
    exit(EXIT_SUCCESS);
}
```

-- CMakeLists.txt:
```
add_executable(util1 util1.c)
add_executable(util2 util2.c)
add_executable(util3 util3.c)
```

- open util1.c
- open the outline and select "configure"
- EXPECTED: it should open the configure in util1.c (or the currently opened file)
- repeat with util2 and util3
- ACTUAL: only one of them works, the other two point to the wrong file.

Reviewers: #kdevelop, mwolff

Reviewed By: #kdevelop, mwolff

Subscribers: mwolff, kdevelop-devel

Tags: #kdevelop

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

Summary:
The TypeSystem::create test was changed as now the destruction is also taken into account for QBENCHMARK

The TopDUContext dtor is protected, however you can execute
delete TopDUContext; but it will NOT call the protected TopDUContext dtor but the public DUContext dtor.

Test Plan:
- compile kdevelop unitest with ASAN&LSAN
- execute test_duchain

Reviewers: #kdevelop, kfunk

Reviewed By: #kdevelop, kfunk

Subscribers: kfunk, kdevelop-devel

Tags: #kdevelop

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

The plugin causes hangs or crashes of KDevelop during some of the most
 common operations.

We haven't received any external bug reports for
 this (nor from 5.0-beta1 to 5.2.1 when the plugin was entirely
 non-functional), so it appears that no-one has attempted to use this
 feature.

Advertising this as a "feature" when it's unusable with no real prospect
 of being fixed will only hurt KDevelop's reputation if anyone does try
 to use it. Of course the code is in git history in case it's wanted in
 future.

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"

Warning:
  .../kdevplatform/shell/sessioncontroller.cpp:371:12: warning: local variable 'l' will be copied despite being returned by name [-Wreturn-std-move]

If I understand that correctly, then e.g. `isTypeParen` has never been
used since it's inception around 2009. It's just that the compiler now
warns about it being unused.

Test seems to be flaky on the KDE CI

```
/tmp/testfile_k23568.cpp:8:12: error: calling a private constructor of class 'A::Q'
/tmp/testfile_k23568.h:1:27: note: implicitly declared private here
/tmp/testfile_k23568.cpp:10:12: error: calling a private constructor of class 'B::Q'
/tmp/testfile_k23568.h:1:27: note: implicitly declared private here
/tmp/testfile_k23568.cpp:12:14: error: 'm' is a private member of 'A::Q'
/tmp/testfile_k23568.h:1:36: note: implicitly declared private here
/tmp/testfile_k23568.cpp:14:14: error: 'm' is a private member of 'B::Q'
/tmp/testfile_k23568.h:1:36: note: implicitly declared private here
```

Unfortunately not easy to add a regression test given the current qmljs
testing infrastructure.

BUG: 396634
FIXED-IN: 5.3.0

Also dont cause horizontal scroll bars by a too-big size hint

... turn into qCDebug (as all others)

CCBUG: 400231

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"

22M uncompressed in size...

... instead of deprecated AppImageAssistant.

Also see:
  https://discourse.appimage.org/t/the-future-of-appimage-type-2-and-new-tools/65

... instead of a prefix containing the major/minor version