Updated class browser

[Hamish Rodda]

On Thursday 02 April 2009 10:18:03 Lior Mualem wrote:
> Hi,
> I've almost finished working on a usable class browser (IMHO).
>
> I've already implemented everything I had in mind so far:
>  * Displays all available classes in the opened projects.
>  * Updates the list dynamically as files in the projects change.
>  * Ability to show base classes for each class
>  * Ability to show derived classes for each class
>  * Filtering ability (using the search box and display the results in a
> special results node).
>  * All of this is done efficiently - if the node is not expanded, it
> requires no CPU cycles (updates monitoring, etc.).
>
>
> I still have 2 problems remaining to resolve and I ask for some help on the
> matters:
>
> 1. After browsing through the classes in the class browser, when I close
> KDevelop, I get the following output in the console followed by a crash:
> SpecialTemplateDeclarationData::m_specializations There were items left on
> destruction: 14
> ClassFunctionDeclarationData::m_defaultParameters There were items left on
> destruction: 5
> ClassDeclarationData::baseClasses There were items left on destruction: 5
> TopDUContextData::m_usedDeclarationIds There were items left on
> destruction: 189
> DUContextData::m_importedContexts There were items left on destruction: 212
> DUContextData::m_childContexts There were items left on destruction: 212
> DUContextData::m_importers There were items left on destruction: 212
> DUContextData::m_localDeclarations There were items left on destruction:
> 212 DUContextData::m_uses There were items left on destruction: 212
>
> The crash stack trace (gdb output):
> --------------------------------------------------
> 0xb60a40f6 in ~DUChainBase (this=0x9682fb0) at
> /home/lior/Projects/KDE/kdevplatform/language/duchain/duchainbase.cpp:79
> 79      if(d_func()->m_dynamic)
> (gdb) bt
> #0  0xb60a40f6 in ~DUChainBase (this=0x9682fb0) at
> /home/lior/Projects/KDE/kdevplatform/language/duchain/duchainbase.cpp:79
> #1  0xb60b9a7d in ~ParsingEnvironmentFile (this=0x9682fb0) at
> /home/lior/Projects/KDE/kdevplatform/language/duchain/parsingenvironment.cp
>p:113 #2  0xac52699d in ~EnvironmentFile (this=0x9682fb0) at
> /home/lior/Projects/KDE/kdevelop/languages/cpp/cppduchain/environmentmanage
>r.cpp:292 #3  0xb7e3c806 in ~KSharedPtr (this=0x9b46cac) at
> /usr/include/ksharedptr.h:84
> #4  0xb604d94d in QMap<KDevelop::IndexedString,
> KSharedPtr<KDevelop::ParsingEnvironmentFile> >::freeData (this=0xb1704734,
> x=0x93f5e80)
>     at /usr/include/qt4/QtCore/qmap.h:587
> #5  0xb604dd12 in ~QMap (this=0xb1704734) at
> /usr/include/qt4/QtCore/qmap.h:147
> #6  0xb604dd35 in ~QMultiMap (this=0xb1704734) at
> /usr/include/qt4/QtCore/qmap.h:901
> #7  0xb6057834 in ~DUChainPrivate (this=0xb17046c8) at
> /home/lior/Projects/KDE/kdevplatform/language/duchain/duchain.cpp:287
> #8  0xb603cc4c in destroy () at
> /home/lior/Projects/KDE/kdevplatform/language/duchain/duchain.cpp:847
> #9  0xb601612d in ~KCleanUpGlobalStatic (this=0xb61a0284) at
> /usr/include/kglobal.h:62
> #10 0xb6410d89 in exit () from /lib/tls/i686/cmov/libc.so.6
> #11 0xb63f868d in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
> #12 0x0804cf51 in _start ()
>
> I'm probably using the DUChains wrong but I have no idea why. Do I need to
> delete myself the declarations that I retrieve from the DUChains? I don't
> recall seeing any mentioning for this in the documentation (except the
> usage of a DUChainPointer which I use).

Don't know, perhaps David has an idea.

> 2. I'm not sure how to monitor class changes efficiently (to reflect
> changes in list of functions / variables) - I'm using DUChainObserver
> retrieved from DUChain::self()->notifier(), I then connect to the
> branchModified signal. The problem with that is that I get 2 notifications
> for each change: 1. The context range for the first call is the entire
> document (by querying the range() function).
>   2. The context range for te second call is zero start and end lines.
> It doesn't matter what I change in the document, class level, function
> level, document level - the results are the same.
>
> Now - I could use this notification and then do the extra work and update
> all the classes that relate to the document but Isn't it suppose to notify
> my on a child context changes (for example the class declaration level
> context)? or am I missing something here?

We once had it that every duchain change was notified, but that was a huge 
performance hit.  Now we just have the branch, and for the moment it just 
reports a change to the whole chain rather than the specifics that changed.

So yes, you have to update all classes that relate to the document.  The old 
code had this, if you want to study it to find out how.

Cheers,
Hamish.