KDevelop issueshttps://invent.kde.org/kdevelop/kdevelop/-/issues2024-01-20T21:41:35Zhttps://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/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/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/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/20[Question] Flutter & Dart Support?2023-01-01T20:38:04ZGhost User[Question] Flutter & Dart Support?Good day KDevelop Devs, I got a question. I am a Software Developer in Training learning Dart & Flutter, I currently use VSCode but want to switch to KDevelop for Dart and Flutter.
Is there a way to accomplish this?
Kind regards
- MrTeeXDGood day KDevelop Devs, I got a question. I am a Software Developer in Training learning Dart & Flutter, I currently use VSCode but want to switch to KDevelop for Dart and Flutter.
Is there a way to accomplish this?
Kind regards
- MrTeeXDhttps://invent.kde.org/kdevelop/kdevelop/-/issues/19A memory leak in test_midbus was recently fixed in a wrong place2023-01-20T11:13:35ZIgor KushnirA memory leak in test_midbus was recently fixed in a wrong place1256df110efb5ceeb720f3e127bf1d7224eaa0de fixed the leak in *midebugsession* code by making a debugger plugin a debug session's parent. However, `DebugController` is responsible for destroying debug sessions, not the debugger plugin. This...1256df110efb5ceeb720f3e127bf1d7224eaa0de fixed the leak in *midebugsession* code by making a debugger plugin a debug session's parent. However, `DebugController` is responsible for destroying debug sessions, not the debugger plugin. This works correctly in KDevelop. See my older fixes: 89ffddc703cead3400122496d286f060b7dcce43 and 37ff587ebe2a2c355d71cb583fb5f058c5301ff3. Potentially destroying a debug session earlier, before the last safe moment in `~DebugController()`, may unnecessarily kill its debugger process. I think the leak should be fixed in the test instead. Does it even create a debug controller? If not, it should provide a minimal replacement for it.
@mwolff, since your commit is the trigger of this issue, could you please comment on it?https://invent.kde.org/kdevelop/kdevelop/-/issues/18Pass a target instead of a CMake variable as the first argument to ecm_qt_dec...2022-12-27T20:47:36ZIgor KushnirPass a target instead of a CMake variable as the first argument to ecm_qt_declare_logging_category()From https://api.kde.org/ecm/module/ECMQtDeclareLoggingCategory.html:
> The generated source file will be added to the variable with the name `<sources_var_name>`. If the given argument is a target though, instead both the generated head...From https://api.kde.org/ecm/module/ECMQtDeclareLoggingCategory.html:
> The generated source file will be added to the variable with the name `<sources_var_name>`. If the given argument is a target though, instead both the generated header file and the generated source file will be added to the target as private sources (since 5.80). The target must not be an alias.
KDevelop already requires KF5 version >= 5.91.0. If we pass a target instead of a CMake variable as the first argument to `ecm_qt_declare_logging_category()`, *debug.h* files will appear in the Quick Open list.
However, sometimes we add the `LOG_SRCS` CMake variable to several targets, e.g. `${cmake_LOG_SRCS}` in [plugins/cmake/CMakeLists.txt](plugins/cmake/CMakeLists.txt). @kossebau, I see that you have implemented the ECM feature in https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/85. Is there a way to add both the generated header file and the generated source file to multiple targets?https://invent.kde.org/kdevelop/kdevelop/-/issues/16test_qmljscompletion always aborts on my system but not on the CI for months now2023-03-06T19:42:23ZIgor Kushnirtest_qmljscompletion always aborts on my system but not on the CI for months nowThe backtrace:[test_qmljscompletion-20221214-170825.kcrash](/uploads/ba71e59a04d42d841d2de6038aafd0b4/test_qmljscompletion-20221214-170825.kcrash)
The crashing test's output:
```
Test #92: test_qmljscompletion .............Subprocess ab...The backtrace:[test_qmljscompletion-20221214-170825.kcrash](/uploads/ba71e59a04d42d841d2de6038aafd0b4/test_qmljscompletion-20221214-170825.kcrash)
The crashing test's output:
```
Test #92: test_qmljscompletion .............Subprocess aborted***Exception: 141.85 sec
********* Start testing of QmlJS::QmlCompletionTest *********
Config: Using QtTest library 5.15.7, Qt 5.15.7 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 12.2.0), manjaro unknown
QWARN : QmlJS::QmlCompletionTest::initTestCase() kdevplatform.serialization: "The data-repository at /home/igor/.qttest/cache/kdevduchain/test_qmljscompletion-{c9e69eca-21ce-453e-984b-f596a514765b} has to be cleared."
PASS : QmlJS::QmlCompletionTest::initTestCase()
QWARN : QmlJS::QmlCompletionTest::testContainsDeclaration(js_outside_single_line_comment) file contents are: "var a // this is a comment;\n"
QFATAL : QmlJS::QmlCompletionTest::testContainsDeclaration(js_outside_single_line_comment) ASSERT failure in {anonymous}::CompletionParameters {anonymous}::prepareCompletion(const QString&, const QString&, bool): "Failed to parse initCode.", file /home/Fast_storage/kdevelop/plugins/qmljs/codecompletion/tests/test_qmljscompletion.cpp, line 88
FAIL! : QmlJS::QmlCompletionTest::testContainsDeclaration(js_outside_single_line_comment) Received a fatal error.
Loc: [Unknown file(0)]
Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted, 1063ms
********* Finished testing of QmlJS::QmlCompletionTest *********
```
Removing all config/data/cache files of *test_qmljscompletion* doesn't get rid of the crash.
@mwolff, does the test crash on your system too?https://invent.kde.org/kdevelop/kdevelop/-/issues/15test_workingsets restoreSplits always fails on my system but not on the CI fo...2022-12-17T07:42:36ZIgor Kushnirtest_workingsets restoreSplits always fails on my system but not on the CI for months nowThe test's output:
```
FAIL! : TestWorkingSetController::restoreSplits() 'sizes_bottom.at(0) < sizes_bottom.at(1)' returned FALSE. ()
Loc: [/path/to/kdevelop/kdevplatform/shell/tests/test_workingsets.cpp(228)]
```
When I comment the...The test's output:
```
FAIL! : TestWorkingSetController::restoreSplits() 'sizes_bottom.at(0) < sizes_bottom.at(1)' returned FALSE. ()
Loc: [/path/to/kdevelop/kdevplatform/shell/tests/test_workingsets.cpp(228)]
```
When I comment the failing check out and add debug output with [this patch](/uploads/dad0af86397cd9391329d97c1b426ef3/test_workingsets.patch), the output is:
```
QSYSTEM: TestWorkingSetController::restoreSplits() sizes_bottom (193, 193)
QSYSTEM: TestWorkingSetController::restoreSplits() sizes_mid (34, 54)
FAIL! : TestWorkingSetController::restoreSplits() Compared lists differ at index 0.
Actual (splitter_bottom->sizes()): 292
Expected (sizes_bottom): 193
Loc: [/path/to/kdevelop/kdevplatform/shell/tests/test_workingsets.cpp(270)]
```
Though most of the time this `QCOMPARE(splitter_bottom->sizes(), sizes_bottom);` check succeeds.
Both the reliable and occasional failure occur in Xfce and KDE Plasma on my Manjaro GNU/Linux system.
89594aed8d4dfa3c7d043e1e6f24c8da93683e88 added the test more than a year ago. I don't know if it ever succeeded on my system.
@croick, does the test fail or succeed on your system? Any ideas how to fix it?https://invent.kde.org/kdevelop/kdevelop/-/issues/14Required version of clang?2022-10-15T01:43:16ZMorten VoldenRequired version of clang?Recent commit 4f341479 raises the required dependency of clang to 11 (or thereabout, I think).
https://github.com/llvm/llvm-project/blame/c7dc9dbaff3a4cda7c23088e77a078a3b57af545/clang/include/clang-c/Index.h
(search for CXType_Atomic)
...Recent commit 4f341479 raises the required dependency of clang to 11 (or thereabout, I think).
https://github.com/llvm/llvm-project/blame/c7dc9dbaff3a4cda7c23088e77a078a3b57af545/clang/include/clang-c/Index.h
(search for CXType_Atomic)
We currently require version 6.0 for clang.
Question is what to do about it?
a) We raise the dependency
b) We do some ifdefs around parts of the code in 4f341479https://invent.kde.org/kdevelop/kdevelop/-/issues/12Follow-up from "Fix "outside the valid range of a QString" runtime warnings"2022-10-19T19:36:55ZMilian WolffFollow-up from "Fix "outside the valid range of a QString" runtime warnings"The following discussion from !378 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/378#note_532632): (+7 comments)
> 5. What about raw string literals?
>...The following discussion from !378 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/378#note_532632): (+7 comments)
> 5. What about raw string literals?
> 6. What about comments and `#if`-conditional blocks? Does libclang remove them from the string before it is parsed here? What about other usages of `findCommaOrEnd()`?https://invent.kde.org/kdevelop/kdevelop/-/issues/11Unable to create a new meson project from template; unable to add meson plugi...2022-10-07T11:59:53ZJohn GlenUnable to create a new meson project from template; unable to add meson plugin through the KDevelop 5.6.1 plugin interfaceIn KDevelop, go to Project->New From Template..
In the standard category, click Get More Templates.
There is no meson plugin to be found.
There is a Meson Project Manager plugin included, but you need an already created meson project to...In KDevelop, go to Project->New From Template..
In the standard category, click Get More Templates.
There is no meson plugin to be found.
There is a Meson Project Manager plugin included, but you need an already created meson project to import, and the stuff I am reading claims you can create a new meson project with a plugin.https://invent.kde.org/kdevelop/kdevelop/-/issues/10Fix a data race in PersistentSymbolTable::filteredDeclarations() API [Follow-...2022-10-07T11:59:53ZIgor KushnirFix a data race in PersistentSymbolTable::filteredDeclarations() API [Follow-up from "Refactor ItemRepository mutex handling"]The following discussion from !328 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/328#note_392693): (+8 comments)
> > The other data structures are still pr...The following discussion from !328 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/328#note_392693): (+8 comments)
> > The other data structures are still protected via the global duchain mutex.
>
> In all functions but `filteredDeclarations()` DUChain is write-locked. Here it is only read-locked while both `m_importsCache` and `m_declarationsCache` are modified. Therefore, this commit may introduce a data race when this function is concurrently called from multiple threads.
>
> Maybe we need to add another mutex to protect the caches? If so, do we still need to ensure DUChain is locked? Alternatively, could we replace `ENSURE_CHAIN_READ_LOCKED` with `ENSURE_CHAIN_WRITE_LOCKED` at the top of this function?
From https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/328#note_452016:
> If I understand correctly, the returned `FilteredDeclarationIterator` references the caches. Seeing that the caches rely on a separate mutex, the duchain lock is not sufficient. Using the returned iterator while another thread calls `PersistentSymbolTable::filteredDeclarations()` constitutes a data race. But if this data race was present even before the changes here, maybe we can merge this as is.Milian WolffMilian Wolffhttps://invent.kde.org/kdevelop/kdevelop/-/issues/9Make ItemRepositoryFor's template arguments consistent [Follow-up from "Refac...2022-10-07T11:59:52ZIgor KushnirMake ItemRepositoryFor's template arguments consistent [Follow-up from "Refactor ItemRepository mutex handling"]The following discussion from !328 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/328#note_392725): (+1 comment)
> I think this should be `ItemRepositoryFor...The following discussion from !328 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/328#note_392725): (+1 comment)
> I think this should be `ItemRepositoryFor<CodeModelRepositoryItem>` for consistency with most other item repositories. Or does this consistency not matter and you've deliberately chosen `CodeModel` for brevity?
>
> Similar inconsistencies (format: `<current type>` inside `ItemRepositoryFor<>` => `<consistent replacement type>`):
> 1. `IndexedIdentifier` => `ConstantIdentifierPrivate`
> 2. `IndexedQualifiedIdentifier` => `ConstantQualifiedIdentifierPrivate`
> 3. `IndexedInstantiationInformation` => `InstantiationInformation`Milian WolffMilian Wolffhttps://invent.kde.org/kdevelop/kdevelop/-/issues/8Clean up ItemRepositoryRegistry [Follow-up from "Refactor ItemRepository mute...2022-10-07T11:59:52ZIgor KushnirClean up ItemRepositoryRegistry [Follow-up from "Refactor ItemRepository mutex handling"]The following discussion from !328 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/328#note_387711): (+3 comments)
> `ItemRepositoryRegistry::unRegisterRepos...The following discussion from !328 should be addressed:
- [ ] @igorkushnir started a [discussion](https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/328#note_387711): (+3 comments)
> `ItemRepositoryRegistry::unRegisterRepository()` - no need for a lock because `unRegisterRepository()` is called only from within `~ItemRepository()`. But there seems to be an inefficiency here: `close()` is called from `unRegisterRepository()` and then immediately from `~ItemRepository()` again. Should perhaps this call be removed from `unRegisterRepository()`?
-------------
More cleanup:
1. `ItemRepositoryRegistry::registerRepository()` is called only from `ItemRepository`'s constructor, so it doesn't need to lock the mutex either.
2. `ItemRepositoryRegistryPrivate::open()` is called only from `ItemRepositoryRegistry`'s constructor. So `m_repositories` is always empty in it, and they don't have to be opened there (an assertion of emptiness could be added instead). This `open()` can become private and be called in `ItemRepositoryPrivate`'s constructor.
3. `ItemRepositoryRegistryPrivate::close()` is called only from `ItemRepositoryRegistry`'s destructor. `ItemRepositoryRegistryPrivate::close()` can be converted into `~ItemRepositoryPrivate()` and the locking of `ItemRepositoryRegistryPrivate::m_mutex` can be removed from the destructors.
4. `ItemRepositoryRegistry` doesn't use `AbstractRepositoryManager`. `ItemRepository` only forwards the manager to `ItemRepositoryRegistry`. Therefore, remove the dependency of these two classes on (remove all mentions of) `AbstractRepositoryManager`. Actually since the class is unused elsewhere too, remove the entire class `AbstractRepositoryManager`. 5128ac8d10df1adabe4575ceaf386a69bc201bdf made this abstract class useless like this:
```diff
~RepositoryManager() {
- deleteRepository();
+ //Don't do this, we don't need it, and it may lead to crashes
+// deleteRepository();
}
```
In `ItemRepositoryRegistryPrivate` change the type of `m_repositories` from `QMap<AbstractItemRepository*, AbstractRepositoryManager*>` to `std::set<AbstractItemRepository*>` and add the following comment above the declaration:
```cpp
// TODO: is the order of repositories important? If not, store them in a QSet rather than std::set.
```https://invent.kde.org/kdevelop/kdevelop/-/issues/7test_files-clang failure with Clang 132022-10-07T11:59:52ZIgor Kushnirtest_files-clang failure with Clang 13_test_files-clang_ consistently fails on KDevelop CI. It started failing on my system after Clang update to version 13.0. A relevant excerpt from the failing test's output:
```
QDEBUG : TestFiles::testFiles(basicdeclsandcontexts.cpp) "id..._test_files-clang_ consistently fails on KDevelop CI. It started failing on my system after Clang update to version 13.0. A relevant excerpt from the failing test's output:
```
QDEBUG : TestFiles::testFiles(basicdeclsandcontexts.cpp) "identifier" FAILED: Declaration's identifier ("(unnamed struct at /home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 SUSEQt5.15/plugins/clang/tests/files/basicdeclsandcontexts.cpp:97:1)") doesn't match test data (""). (Declaration on line 97 in /home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 SUSEQt5.15/plugins/clang/tests/files/basicdeclsandcontexts.cpp)
QDEBUG : TestFiles::testFiles(basicdeclsandcontexts.cpp) "identifier" FAILED: Declaration's identifier ("(unnamed union at /home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 SUSEQt5.15/plugins/clang/tests/files/basicdeclsandcontexts.cpp:100:1)") doesn't match test data (""). (Declaration on line 100 in /home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 SUSEQt5.15/plugins/clang/tests/files/basicdeclsandcontexts.cpp)
FAIL! : TestFiles::testFiles(basicdeclsandcontexts.cpp) 'validator.testsPassed()' returned FALSE. ()
Loc: [/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 SUSEQt5.15/plugins/clang/tests/test_files.cpp(116)]
```
I attempted to fix the test failure, but realized that this is not a straightforward task. The declaration's identifier contains an absolute path, so cannot be included in a comment in the file *kdevelop/plugins/clang/tests/files/basicdeclsandcontexts.cpp*. Plus the identifier is empty in Clang versions < 13.
Fortunately, these failing test cases are the only ones that have an empty identifier. So the test cases can be referred to as `pair("identifier", "")` and fixed or worked around.
Possible solutions:
1. Remove the two unnamed-object declarations that cause the failure. This solution is trivial to implement, but reduces test coverage.
2. Expand `DeclarationValidator`'s and possibly `TestSuite`'s interfaces to be able to pass test data fix-ups at runtime. This solution is much more tricky and time-consuming to implement. But if done right, could let us fix similar issues in the future - without removing tests. Unfortunately I don't know how to do this right and even if it is worth doing.Igor KushnirIgor Kushnir