Created attachment 178190 [details] sample project SUMMARY The code completion (ctrl+space) with regards to using the implement function will show every qt signal that is in the 'signals' section in the code. in some cases this is 50+ signals that always show needing to be implemented (when they shouldn't be) i have attached a small cmake project STEPS TO REPRODUCE 1. Open code completion 2. 'type f' to show foo class implementations OBSERVED RESULT the signal in the foo class will be in the list EXPECTED RESULT signals should not be in the list to implement, as they are not supposed to be implemented outside of moc SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Have you worked around Bug 499768? Is this bug limited to the AppImage? I haven't encountered such an issue.
(In reply to Igor Kushnir from comment #1) > Have you worked around Bug 499768? Is this bug limited to the AppImage? I > haven't encountered such an issue. yes. i worked around it by installing clang 18 on my pc and setting the environment KDEV_CLANG_BUILTIN_DIR to the path.
though i cant tell you yet if this bug is specifically the appimage or if it's just the latest nightly in general, as i havent tried to rebuild from source (the reason i'm using the nightly instead is because it's simpler than building from source)
(In reply to Ian H from comment #3) > though i cant tell you yet if this bug is specifically the appimage or if > it's just the latest nightly in general, as i havent tried to rebuild from > source (the reason i'm using the nightly instead is because it's simpler > than building from source) I am using almost latest KDevelop, so probably an AppImage bug, maybe even a consequence of the (possibly incomplete) workaround. I also don't recall any recent change that could possibly cause such a bug.
alright. i guess it's time for me to bite the bullet again and rebuild from source (yuck)
(In reply to Ian H from comment #5) > alright. i guess it's time for me to bite the bullet again and rebuild from > source (yuck) Is KDevelop Flatpak broken too?
(In reply to Igor Kushnir from comment #6) > (In reply to Ian H from comment #5) > > alright. i guess it's time for me to bite the bullet again and rebuild from > > source (yuck) > Is KDevelop Flatpak broken too? dont know. i'll try it now and report bugs when i break it.
to answer your question, yes. the parsing on the flatpak version is also broken