There is following code: header: #include <QString> class MyClass { public: /** This function something do. * @param pointer some pointer * @param string some string */ MyClass( int *pointer, const QString &string ); private: bool m_bSomeGlobalMember; }; definition: #include "myclass.h" MyClass::MyClass( int *pointer, const QString &string ) { int *localPointer = pointer; QString localString = string; bSomeGlobalMember = true; } When I remove member "bSomeGlobalMember" from header file then in cpp properly line(s) are not marked as incorrect only changes color to dark red. Problem view doesn't report any problem. Case 1: When I back to header and restore just removed member pressing Ctrl+Z then switching to cpp I will have correct color of member. Please note that in bigger (then 2 files) project it might take more time or doesn't work properly just leaving wrong coloring. I experienced it in my own project. It was really annoying. I had to close KDevelop, remove cache and start KDevelop again to have correctly parsed file :-/. Case 2: I don't restore member in header, but I'm starting write something, for example, in last empty line of constructor. Parser wakes up and I get marks line where is used removed member. Reproducible: Always Steps to Reproduce: 1. Being in header please remove member "bSomeGlobalMember" just pressing Ctrl+K (remove line) on this line. 2. Please switch to cpp file and look at removed in header member. Actual Results: Member changes color to dark red. There is no reported error in Problem view. Expected Results: Every use of member should be marked as error. In Problem view should be reported such problem. KDevelop and KDevplatform cloned at December 5-th 2015. Branch "5.0". I attach package containing simple project.
Created attachment 95911 [details] simple test project
I've seen this myself. There seems to be some issues with dependency tracking and/or rehighlighting files of the TU.
Git commit 81011039d34d2e715135f024a67b68cdf5ee913b by Milian Wolff. Committed on 23/01/2016 at 18:42. Pushed by mwolff into branch '5.0'. Always update the DUChain for the translation unit file. This is required to properly update .cpp files to reflect changes in header files. This patch is just a quick fix for the common case, we might still run into issues for header files that depend on other header files which got updated. Also note that we need to introduce a central "DUChain::updateReady" signal or similar, together with a mechanism to trigger that from within the clang parse job. This is the reason why often the problem view is not updating itself, leading to outdated highlighting of those. Thing is: The problem view only listens to the background parser's update signals, which do not get emitted for .cpp files when the .h file is changed e.g. This is due to the different way the clang lang plugin runs (single job can update multiple files), compared to the oldcpp lang plugin (single job for single file). M +7 -1 languages/clang/duchain/clanghelpers.cpp http://commits.kde.org/kdevelop/81011039d34d2e715135f024a67b68cdf5ee913b
Git commit 73b9e10fdd388e8b8dce2db0101bd1c9c1d76e7b by Milian Wolff. Committed on 23/01/2016 at 22:18. Pushed by mwolff into branch '5.0'. Introduce a new DUChain::updateReady signal. This is necessary to reliably track updates to the DUChain data. The Clang parse job as a one-to-many relationship between the parse job and to files it may trigger DUChain updates of. Previously, a one-to-one relationship was always assumed, which now uncovered various issues throughout KDevelop: - assistants did not get properly updated - problems and the highlighting of them did not update properly - sometimes the context browser was also broken - ... Basically everywhere the code listened to finished ParseJobs to update state when the DUChain was modified now broke apart. This new signal simplifies code and fixes these issues. Note that language plugins must call DUChain::emitUpdateReady now to notify the world about updates. I tried to do this automatically but we need a dedicated function as only language plugins know when to emit this, i.e. when all processing on a given file has finished. NOTE: THIS REQUIRES AN UPDATE TO ALL LANGUAGE PLUGINS! M +0 -1 language/assistant/renameassistant.h M +8 -10 language/assistant/staticassistantsmanager.cpp M +0 -1 language/assistant/staticassistantsmanager.h M +6 -0 language/backgroundparser/backgroundparser.h M +0 -1 language/classmodel/classmodel.h M +14 -7 language/duchain/duchain.cpp M +14 -0 language/duchain/duchain.h M +4 -6 plugins/contextbrowser/contextbrowser.cpp M +2 -2 plugins/contextbrowser/contextbrowser.h M +6 -9 plugins/outlineview/outlinemodel.cpp M +0 -2 plugins/outlineview/outlinemodel.h M +2 -10 plugins/problemreporter/problemreporterplugin.cpp M +1 -4 plugins/problemreporter/problemreporterplugin.h M +0 -1 plugins/problemreporter/problemtreeview.h M +0 -4 util/duchainify/main.h http://commits.kde.org/kdevplatform/73b9e10fdd388e8b8dce2db0101bd1c9c1d76e7b
Git commit 2947a8b43895db23bc8406a0acfc9b2a2fc6d9eb by Milian Wolff. Committed on 23/01/2016 at 22:25. Pushed by mwolff into branch '5.0'. Update to KDevplatform changes, prefer to use DUChain::updateReady and call DUChain::emitUpdateReady. This fixes several issues with the clang language plugin where other plugins did not get notified about DUChain updates as many files can be updated from within a single clang parsejob. M +4 -6 languages/clang/codegen/adaptsignatureassistant.cpp M +1 -5 languages/clang/codegen/adaptsignatureassistant.h M +2 -0 languages/clang/duchain/clanghelpers.cpp M +4 -4 languages/cpp/codecompletion/model.cpp M +1 -2 languages/cpp/codecompletion/model.h M +4 -7 languages/cpp/codegen/adaptsignatureassistant.cpp M +1 -5 languages/cpp/codegen/adaptsignatureassistant.h M +1 -0 languages/cpp/cppparsejob.cpp M +2 -0 languages/qmljs/qmljsparsejob.cpp M +1 -0 projectmanagers/cmake/duchain/cmakeparsejob.cpp http://commits.kde.org/kdevelop/2947a8b43895db23bc8406a0acfc9b2a2fc6d9eb