DU-chain classes questions ...

[David Nolden]

First an overview of the different declaration pointers:
Declaration*   :   A simple pointer, only guaranteed to be valid
within one duchain lock cycle. After you unlocked the duchain, you
must not use a stored pointer any more, as it may have been deleted or
unloaded, leading to a crash.

DeclarationPointer    : A weak pointer to a declaration, which notices
when the declaration was deleted, returning zero if that's the case.
This class is old though, and somewhat superseded by
IndexedDeclaration.

IndexedDeclaration     :  A very efficient reference to a declaration
by its indices. Generally the functionality is similar to
DeclarationPointer, but it does not impose any additional
memory-overhead for the KShared stuff, and it is persistent (can be
stored to disk, and it can trigger loading of a top-context from disk
if it has been unloaded out of memory)

LocalIndexedDeclaration    :  Like IndexedDeclaration, except that it
is slightly smaller and doesn't store the top-context index, so it
gets the top-context handed directly. Used only internally by
DUContext to save disk space and memory.

DeclarationId     :     Does not refer one declaration object
specifically, but rather just a declaration by its identifier. When
the declaration is requested, it is looked up in the symbol table. A
DeclarationId needs to get a top-context handed, and may return
different declarations depending on the declarations included into
that context. For example when you have the class "C" declared within
two different files, you will always get the declaration within the
file you give the top-context for. The big advantage of this class is
that it is even more "correct" and persistent than IndexedDeclaration,
as an IndexedDeclaration can also be invalidated sometimes when a
declaration was deleted and re-created.

2010/4/15 Sandro Andrade <sandro.andrade at gmail.com>:
>> > 6) If I select a new symbol while collecting uses, apparently the
>> > collect
>> > is paused and resumed from the last point if first symbol is selected
>> > again. The pause point can be restored from m_waitForUpdate and
>> > m_updateReady QSets in UsesCollector, but the question is: are the
>> > remaining updateContextForUrl calls cancelled when a new symbol is
>> > selected ? Or do they run to completion ?

Usually many context updates are requested to find the uses of one
object (for all files that include a definition of a searched symbol).
All the updates are queued into the background parser, and when the
user stops the search, then the updates are removed again from the
background-parser through backgroundParser::revertAllRequests.
Next time the symbol is searched the same files will be requested for
updating, but since they were already updated last time, they are
returned instantly without having to wait, so it looks as if the
search was "continued".

As for efficiency: If you have a problem with the efficiency, then I
guess you have to reduce the "backwards" expansion of the control flow
graph, and maybe let the user do the expansion manually by clicking if
he likes.

Greetings, David