KDevelop issueshttps://invent.kde.org/kdevelop/kdevelop/-/issues2024-03-28T11:56:44Zhttps://invent.kde.org/kdevelop/kdevelop/-/issues/41Wrong Download Links (https://binary-factory.kde.org/)2024-03-28T11:56:44ZMax WilfingerWrong Download Links (https://binary-factory.kde.org/)_As mentioned and fixed in Kate the KDevelop has the same issue: https://invent.kde.org/utilities/kate/-/issues/117_
The download links on https://kdevelop.org/de/download/ link all to https://binary-factory.kde.org/ and it is not possi..._As mentioned and fixed in Kate the KDevelop has the same issue: https://invent.kde.org/utilities/kate/-/issues/117_
The download links on https://kdevelop.org/de/download/ link all to https://binary-factory.kde.org/ and it is not possible to download the packages.
Unfortunately it is not possible to install KDevelop on macOS or Windows as the links are dead.
Maybe you can also ping other KDE developers to check for their applications.https://invent.kde.org/kdevelop/kdevelop/-/issues/40BreakpointModel code assumes IDocument::url() is the same as KTextEditor::Doc...2024-03-12T16:05:11ZIgor KushnirBreakpointModel code assumes IDocument::url() is the same as KTextEditor::Document::url()The two `url()`s differ for untitled (new, unsaved) documents: `QUrl("file:///Untitled") != QUrl("")` (see `DocumentController::nextEmptyDocumentUrl()`). A breakpoint can be added to an untitled document, but bugs ensue. For example, re...The two `url()`s differ for untitled (new, unsaved) documents: `QUrl("file:///Untitled") != QUrl("")` (see `DocumentController::nextEmptyDocumentUrl()`). A breakpoint can be added to an untitled document, but bugs ensue. For example, removing a breakpoint from an untitled document leaves its breakpoint mark intact.https://invent.kde.org/kdevelop/kdevelop/-/issues/39Follow-up from "debugger: document reload and mark work"2024-03-18T09:29:46ZIgor KushnirFollow-up from "debugger: document reload and mark work"The following discussions from !524 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/524#note_859879): (+4 comments)
> I just noticed an unfortunate long chai...The following discussions from !524 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/524#note_859879): (+4 comments)
> I just noticed an unfortunate long chain of interleaving nested `Breakpoint` and `BreakpointModel` calls:
> `BreakpointModel::addCodeBreakpoint()` => `Breakpoint::setLocation()` => `Breakpoint::updateMovingCursor()` => `BreakpointModel::setupMovingCursor()` => `Breakpoint::setMovingCursor()` => `BreakpointModel::updateBreakpointMark()`. Ideally this back-and-forth should be refactored away (maybe not in this merge request).
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/524#note_863700): (+19 comments)
> Check whether a type cast is needed here by making it fail (e.g. change the type to disabled-breakpoint) and learning whether `QCOMPARE` prints the actual and expected values.
- [x] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/524#note_863709): (+23 comments)
> typo: "be not be"
>
> Are `aboutToReload()` and `reloaded()` emitted if user selects other than "Discard"? If not, why place this comment here?
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/524#note_869693): (+12 comments)
> Just got this assertion to fail:
> 1. Create a breakpoint.
> 2. Remove all document text starting from some line above the breakpoint.
> 3. Save the document.
> * At this point the breakpoint's line is set to the number of lines in the document, which I think is wrong.
> 4. Ctrl+Z to restore the removed text.
> 5. Uncheck the invisible breakpoint's Enabled checkbox in the Breakpoints tool view.
> * `ASSERT: "oldMarkType"`
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/524#note_873607): (+3 comments)
> When I try to break the tests by changing the expected enumerator, I get uninformative `QCOMPARE` output:
>
> ```
> FAIL! : TestBreakpointModel::testUpdateMarkType() Compared values are not the same
> Loc: [/home/Fast_storage/kdevelop/kdevplatform/debugger/tests/test_breakpointmodel.cpp(487)]
> FAIL! : TestBreakpointModel::testDocumentReload() Compared values are not the same
> Loc: [/home/Fast_storage/kdevelop/kdevplatform/debugger/tests/test_breakpointmodel.cpp(518)]
> ```
>
> This is a general problem with enums. Maybe add template specializations into this cpp file, e.g.:
> ```cpp
> namespace QTest {
> template<>
> inline char* toString(const IDocument::DocumentState& state)
> {
> return toString(static_cast<int>(state));
> }
> }
> ```
>
> (the `DocumentState` specialization can actually be inserted into *kdevplatform/tests/testhelpers.h* in a separate commit)https://invent.kde.org/kdevelop/kdevelop/-/issues/38KDevelop not opening despite no issues2024-01-20T21:41:35Zori raisfeldKDevelop not opening despite no issuesi just installed kdevelop using snap, and for some reason, KDevelop doesn't seem to do anything when running the application. there's no error message and the app doesnt close, it just stays the same untill i press CTRL+C which closes th...i just installed kdevelop using snap, and for some reason, KDevelop doesn't seem to do anything when running the application. there's no error message and the app doesnt close, it just stays the same untill i press CTRL+C which closes the app.
here is my console output:
```plaintext
Qt WebEngine seems to be initialized from a plugin. Please set Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute before constructing QGuiApplication.
```
(the application doesn't end, it just stays like this. i waited around 10 minutes for anything to show up and nothing did)
i am using 6.6.10-1-MANJARO with Plasma 5.27.10
EDIT: i tried to remove the snap version and install KDevelop from pamac and it solved the issue. i think this is a version issue or something, so i'm going to close this since the issue is in snap, not in KDevelop itselfhttps://invent.kde.org/kdevelop/kdevelop/-/issues/37Kdevelop version is unclear in the downstream packing ecosystem2023-12-20T18:43:51ZKunda KiKdevelop version is unclear in the downstream packing ecosystemApologies for opening ticket here, my login for bugs.kde.org doesn't work ATM. My hope is to signal to the devs here the following issues:
<a href="https://repology.org/project/kdeconnect/versions">
<img src="https://repology.org/ba...Apologies for opening ticket here, my login for bugs.kde.org doesn't work ATM. My hope is to signal to the devs here the following issues:
<a href="https://repology.org/project/kdeconnect/versions">
<img src="https://repology.org/badge/vertical-allrepos/kdeconnect.svg?columns=3" alt="Packaging status">
</a>
As it can be seen in the above repology badge (besides obsolete versions of Kdevelop) there is inconsistencies between downstream packages. One of the reasons may be due to KDevelop website news page [last post](https://kdevelop.org/news/) is for v5.6.1 from Dec 2020:
![Screenshot_20231220_104539](/uploads/515a09470e90d60551a8a78b0d0e029f/Screenshot_20231220_104539.png)
It looks like the issue is that KDevelop is now part of KDE Gear and so it's versioning is superseded by Gear versioning...
Perhaps this issue is a duplicate of #34 in that case ?
There is also no changelog to parse in the gitlab repository besides the CMake file which just provides the KDE Gear version number. Is that by design ?https://invent.kde.org/kdevelop/kdevelop/-/issues/36Remove unused Breakpoint::m_address and consider using expression() in place ...2023-11-26T14:21:05ZIgor KushnirRemove unused Breakpoint::m_address and consider using expression() in place of address() in MIBreakpointController::breakpointAdded()The following discussion from !515 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/515#note_815540): (+8 comments)
> So you have verified that these change r...The following discussion from !515 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/515#note_815540): (+8 comments)
> So you have verified that these change reports are redundant in all KDevelop code, but still not sure they can be removed? Because of out-of-tree debugger plugins?https://invent.kde.org/kdevelop/kdevelop/-/issues/35Do not annotate types that can be disk-reference-counted with Q_MOVABLE_TYPE2023-11-09T19:19:27ZIgor KushnirDo not annotate types that can be disk-reference-counted with Q_MOVABLE_TYPE`DUChainReferenceCounting` stores addresses of disk-reference-counted objects. Moving a disk-reference-counted object's bytes to another location in memory thus breaks reference counting.
Distinct lightweight view types, e.g. `IndexedSt...`DUChainReferenceCounting` stores addresses of disk-reference-counted objects. Moving a disk-reference-counted object's bytes to another location in memory thus breaks reference counting.
Distinct lightweight view types, e.g. `IndexedStringView`, should be used in known non-disk-reference-counted contexts, especially where performance matters.
467371ab2d53d3373051600f687e0e9351371443 introduced many such wrong `Q_MOVABLE_TYPE` annotations.
See also a17d3f65dbdcc583943b7f6188766e6d0ceca212 and 834fb13b89f917362ba5a0724170b46cb099df9d.https://invent.kde.org/kdevelop/kdevelop/-/issues/34Use KDE Gear versioning in all places2023-12-20T15:49:58ZJustin ZobelUse KDE Gear versioning in all placesAs KDevelop is part of KDE Gear, is it possible to use just the Gear versioning in the appdata in future versions?
https://invent.kde.org/kdevelop/kdevelop/-/commit/a87600d72101aa6961058aa46f9c5c842038e268As KDevelop is part of KDE Gear, is it possible to use just the Gear versioning in the appdata in future versions?
https://invent.kde.org/kdevelop/kdevelop/-/commit/a87600d72101aa6961058aa46f9c5c842038e268https://invent.kde.org/kdevelop/kdevelop/-/issues/33support to run html and php files in the browser directly and see the changes...2023-10-10T08:11:43Zapi api devsupport to run html and php files in the browser directly and see the changes we make to the files in real time.Hello, I like kdeveloper to program html and php files, there will be support in the future so that we can run them in the browser directly and see the changes we make to the files in real time such as brackets or visual studio code. Tha...Hello, I like kdeveloper to program html and php files, there will be support in the future so that we can run them in the browser directly and see the changes we make to the files in real time such as brackets or visual studio code. Thanks for such an excellent ide. I use it on Windows and by the way there is a problem with the dark themes, it does not allow me to see the IDE menus.https://invent.kde.org/kdevelop/kdevelop/-/issues/32libclang crash in libcxx2023-10-05T14:41:07ZGleb Popov6yearold@gmail.comlibclang crash in libcxxMy KDevelop is unusable for a long time with any C++ project. I finally found time to dive in and here's what I found.
Things seems to start being wrong on
```
#4 0x0000000826e511d3 in clang::FieldDecl::getBitWidthValue (this=<optimiz...My KDevelop is unusable for a long time with any C++ project. I finally found time to dive in and here's what I found.
Things seems to start being wrong on
```
#4 0x0000000826e511d3 in clang::FieldDecl::getBitWidthValue (this=<optimized out>, Ctx=...) at /wrkdirs/usr/ports/devel/llvm15/work-default/llvm-project-15.0.7.src/clang/lib/AST/Decl.cpp:4283
4283 return getBitWidth()->EvaluateKnownConstInt(Ctx).getZExtValue();
(gdb) print Ctx
$27 = (const clang::ASTContext &) <error reading variable: Cannot access memory at address 0x76098f8>
```
Going up one frame I get
```
#5 0x00000008261aea78 in (anonymous namespace)::Visitor::setDeclData<(CXCursorKind)6> (this=0x7fffdbbde0b0, cursor=..., decl=0x84d614930) at /wrkdirs/usr/ports/devel/kdevelop/work/kdevelop-23.08.1/plugins/clang/duchain/builder.cpp:1157
1157 decl->setBitWidth(clang_getFieldDeclBitWidth(cursor));
(gdb) print decl->toString()
$28 = "<notype> __cap_"
```
The `<notype>` looks strange. Maybe this is what cause a crash?
Dumping the libclang's `CXCursor` reveals the part it chokes on:
```
(gdb) print ((char*)(*(&clang_getCursorPrettyPrinted))(cursor, 0))
$18 = 0x84d626780 "std::basic_string::size_type __cap_ : sizeof(std::basic_string::size_type) * 8 - 1"
```
It corresponds to the following part of the `<string>` libc++ header: https://github.com/llvm/llvm-project/blob/release/15.x/libcxx/include/string#L743
The important thing about my setup is that KDevelop uses libclang that comes from LLVM 15 while the system ships libc++ headers from LLVM 16. While this also may cause some subtle issues, the code I linked seems to be the same for both 15 and 16 versions.
If anyone have an idea how to debug this further it'd be really appreciated.Gleb Popov6yearold@gmail.comGleb Popov6yearold@gmail.comhttps://invent.kde.org/kdevelop/kdevelop/-/issues/31KDE Terminal Opens in Home Directory instead of in Project Directory2023-09-26T18:16:23ZChris HalbersmaKDE Terminal Opens in Home Directory instead of in Project DirectoryWhen opening up or reopening up a session. The integrated terminal in kdevelop opens up in the home directory. You have to exit the terminal for it to open up in the project directory.
Application is installed from flathub :
```
chalb...When opening up or reopening up a session. The integrated terminal in kdevelop opens up in the home directory. You have to exit the terminal for it to open up in the project directory.
Application is installed from flathub :
```
chalbersma@abtripv3:~> flatpak list | grep -i kdevelop
KDevelop org.kde.kdevelop 5.12.230800 stable system
```
Running on OpenSuse Tumbleweed.https://invent.kde.org/kdevelop/kdevelop/-/issues/30TestDeclarations::testQMLtypesImportPaths fails on the CI because of missing ...2023-08-10T08:54:34ZIgor KushnirTestDeclarations::testQMLtypesImportPaths fails on the CI because of missing QtQuick.XmlListModel moduleThe following error is present in CI build logs for months now:
```
FAIL! : TestDeclarations::testQMLtypesImportPaths() 'QFileInfo::exists(path + "/plugins.qmltypes")' returned FALSE. ()
Loc: [/builds/kdevelop/kdevelop/plugins/qmljs/...The following error is present in CI build logs for months now:
```
FAIL! : TestDeclarations::testQMLtypesImportPaths() 'QFileInfo::exists(path + "/plugins.qmltypes")' returned FALSE. ()
Loc: [/builds/kdevelop/kdevelop/plugins/qmljs/duchain/tests/test_qmljsdeclarations.cpp(267)]
```
The relevant test code at the lines 266-267 of *test_qmljsdeclarations.cpp* is:
```cpp
path = QmlJS::Cache::instance().modulePath(stubPath, QStringLiteral("QtQuick.XmlListModel"), QStringLiteral("2.0"));
QVERIFY(QFileInfo::exists(path + "/plugins.qmltypes"));
```
I think the test started failing because of https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/214. I suspect that inserting the following line into https://commits.kde.org/craft-blueprints-kde?path=extragear/kdevelop/kdevelop/kdevelop.py will fix the test failure:
```python
self.runtimeDependencies["libs/qt5/qtxmlpatterns"] = None
```
But I am not sure it's the right fix, because KDevelop doesn't seem to use the *QtQuick.XmlListModel* module anywhere except in the failing test. *plugins/welcomepage/qml/NewsFeed.qml* uses this module, but the news feed itself has been unconditionally disabled since c6665446. So perhaps instead of adding the *qtxmlpatterns* dependency, the test should detect the absence of *QtQuick.XmlListModel* and skip the now-failing check in that case.https://invent.kde.org/kdevelop/kdevelop/-/issues/29Last-modified timestamps of external CMake files that belong to system packag...2023-06-08T13:52:09ZIgor KushnirLast-modified timestamps of external CMake files that belong to system packages can be too old[Here](https://invent.kde.org/kdevelop/kdevelop/-/blob/adb192cf63a33b5a9492d8a8de7fe11bee57e83d/plugins/cmake/cmakefileapi.cpp#L290) KDevelop relies on CMake file timestamps. A CMake file, such as */usr/lib/cmake/Qt5/Qt5ConfigVersion.cma...[Here](https://invent.kde.org/kdevelop/kdevelop/-/blob/adb192cf63a33b5a9492d8a8de7fe11bee57e83d/plugins/cmake/cmakefileapi.cpp#L290) KDevelop relies on CMake file timestamps. A CMake file, such as */usr/lib/cmake/Qt5/Qt5ConfigVersion.cmake*, has the last-modified timestamp of the time when the package was built by a distro maintainer. The package can be installed (updated) on an end user's system much later. If the last build of a program, which depends on such a CMake file, is made between these two dates, KDevelop considers the CMake API reply index file up-to-date and doesn't rerun the CMake configure and generate steps. The build then fails with an error like this:
> ninja: error: '/usr/lib/libQt5Core.so.5.15.8', needed by '/path/to/program/lib.so', missing and no known rule to make it
The user has to figure out that CMake configure needs to be rerun manually or the project reloaded in KDevelop. I personally wasted quite some time before figuring this out.
Can we somehow detect the issue and rerun CMake? Or at least show a general hint about the issue somewhere to help the users understand the problem and the solution faster?https://invent.kde.org/kdevelop/kdevelop/-/issues/28Better CMakeLists.txt handling2023-04-29T18:52:31Zbufa lo1973Better CMakeLists.txt handlingI think CMakeLists.txt should change if you change options in project configuration. And it would be great if creating a code file included adding it to the CMakeLists.txt file.
(Note: I see this more a wish than an issue)I think CMakeLists.txt should change if you change options in project configuration. And it would be great if creating a code file included adding it to the CMakeLists.txt file.
(Note: I see this more a wish than an issue)https://invent.kde.org/kdevelop/kdevelop/-/issues/27LSP Overrides Editor Theme2023-03-26T18:40:55ZBo-Ru JuLSP Overrides Editor ThemeI noticed that certain colors of set KSyntaxHighlighting theme are overridden when project parsing is enabled
Kate does not have this issue possibly due to [this](https://invent.kde.org/utilities/kate/-/merge_requests/198/diffs) PR
Bug...I noticed that certain colors of set KSyntaxHighlighting theme are overridden when project parsing is enabled
Kate does not have this issue possibly due to [this](https://invent.kde.org/utilities/kate/-/merge_requests/198/diffs) PR
BugZilla seems to be inactivate, so I submitted here
[Similar issue](https://bugs.kde.org/show_bug.cgi?id=395855) can be found there
Also found [this](https://unix.stackexchange.com/questions/223343/problem-changing-kdevelop-color-scheme)https://invent.kde.org/kdevelop/kdevelop/-/issues/26Remove/Update Appimage support2023-03-26T18:37:31ZAntónio MonteiroRemove/Update Appimage supportIn my opinion appimage support should be removed or updated (using the opensuse image) as the last "real" commit dates back 2020 (3 years old!) and the docker file is using CentOS which is unsupported.In my opinion appimage support should be removed or updated (using the opensuse image) as the last "real" commit dates back 2020 (3 years old!) and the docker file is using CentOS which is unsupported.https://invent.kde.org/kdevelop/kdevelop/-/issues/25What can possibly make `test_quickopen testProjectFileFilter` flaky?2023-03-06T15:46:57ZIgor KushnirWhat can possibly make `test_quickopen testProjectFileFilter` flaky?`TestQuickOpen::testProjectFileFilter()` fails on the CI occasionally: [suse_tumbleweed_qt515](https://invent.kde.org/kdevelop/kdevelop/-/pipelines/306711/test_report), [freebsd_qt515](https://invent.kde.org/kdevelop/kdevelop/-/pipelines...`TestQuickOpen::testProjectFileFilter()` fails on the CI occasionally: [suse_tumbleweed_qt515](https://invent.kde.org/kdevelop/kdevelop/-/pipelines/306711/test_report), [freebsd_qt515](https://invent.kde.org/kdevelop/kdevelop/-/pipelines/316050/test_report). I recall it has failed on my system in the past. I run *test_quickopen* tens of times and the single _testProjectFileFilter_ test case hundreds of times in a row, and couldn't reproduce the test failure.
The failing test's output:
```
QDEBUG : TestQuickOpen::testProjectFileFilter() ("foo/asdf", "asdf/bar", "foo/bar", "foo/space bar")
FAIL! : TestQuickOpen::testProjectFileFilter() Compared lists have different sizes.
Actual (items(provider)) size: 4
Expected (QStringList() << QStringLiteral("foo/asdf") << QStringLiteral("asdf/bar")) size: 2
Loc: [/builds/kdevelop/kdevelop/plugins/quickopen/tests/test_quickopen.cpp(386)]
```
I examined `BaseFileDataProvider::setFilterText()` and `PathFilter::setFilter()`: both definitions are synchronous and deterministic. So how can the test possibly fail occasionally? Does some Quick Open filtering UI become interactable for a short while, which interferes with the filtering?https://invent.kde.org/kdevelop/kdevelop/-/issues/24Implement clang_hashType() in libclang and use it in TypeCacheKey2023-01-28T17:04:35ZIgor KushnirImplement clang_hashType() in libclang and use it in TypeCacheKeyThe following discussion from !424 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/424#note_598337): (+3 comments)
> **A way to greatly optimize the cache-re...The following discussion from !424 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/424#note_598337): (+3 comments)
> **A way to greatly optimize the cache-related work, which I'd like to implement myself**
>
> The idea is to avoid calling `clang_getTypeSpelling()` by hashing two pointers, relying on the current implementation of [`clang_equalTypes()`](https://github.com/llvm/llvm-project/blob/main/clang/tools/libclang/CXType.cpp#L645). Plus add some assertions to detect libclang implementation changes:
> ```cpp
> static_assert(sizeof(CXType) == 3 * sizeof(void*));
>
> bool operator==(const TypeCacheKey& rhs) const noexcept
> {
> const bool equal = data()[0] == rhs.data()[0] && data()[1] == rhs.data()[1];
> #if !defined(QT_NO_DEBUG) || defined(QT_FORCE_ASSERTS)
> Q_ASSERT(equal == clang_equalTypes(m_type, rhs.m_type));
> #endif
> return equal;
> }
> ```
>
> Memory would also be saved because with assertions disabled `sizeof(TypeCacheKey) == 2 * sizeof(void*)` could be achieved.
>
> If the stability of `clang_equalTypes()` is in doubt, I can implement this efficient hash function in libclang as `clang_hashType()`. KDevelop would use the new function if the Clang version is fresh enough and fall back to the custom code otherwise. Or, alternatively, always use inline custom code, but verify that the hash value is correct by checking `clang_hashType()` in an assertion. The implementation of `clang_equalTypes()` hasn't changed since its [introduction 12 years ago](https://github.com/llvm/llvm-project/commit/6bca984b5438540fd6433e9fa10009241a139fbb).Igor KushnirIgor Kushnirhttps://invent.kde.org/kdevelop/kdevelop/-/issues/23Adjust out-of-tree plugins to KDevPlatform AbstractType and TypePtr API cleanups2023-01-24T15:10:15ZIgor KushnirAdjust out-of-tree plugins to KDevPlatform AbstractType and TypePtr API cleanupsThe following discussion from !424 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/424#note_597961): (+1 comment)
> `cast()` is used in several out-of-tree p...The following discussion from !424 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/424#note_597961): (+1 comment)
> `cast()` is used in several out-of-tree plugins. Search for "kdev" on [this page](https://lxr.kde.org/ident?v=kf5-qt5&_i=cast&_remember=1).
* search on LXR for all public API renamed and removed in !424 to see which plugins use it;
* make the affected plugins compile again.https://invent.kde.org/kdevelop/kdevelop/-/issues/22Remove or deprecate AbstractTypeBuilder::openAbstractType() and Declaration::...2023-01-16T10:48:38ZIgor KushnirRemove or deprecate AbstractTypeBuilder::openAbstractType() and Declaration::setAbstractType()The following discussion from !424 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/424#note_597956): (+2 comments)
> `openAbstractType` is used [only in kdev...The following discussion from !424 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/424#note_597956): (+2 comments)
> `openAbstractType` is used [only in kdev-php and umbrello's bundled copy of it](https://lxr.kde.org/ident?v=kf5-qt5&_i=openAbstractType&_remember=1). If we don't remove it outright and adjust the uses, maybe at least deprecate `openAbstractType`? The compiler warning will hopefully get rid of these usages and let us remove `openAbstractType` without hassle eventually.