• Skip to content
  • Skip to link menu
KDE 4.4 API Reference
  • KDE API Reference
  • KDevelop Platform Libraries
  • Sitemap
  • Contact Us
 

language/duchain

Todo List

Page Implementing Definition-Use Chains for a specific language
complete this section

Member KDevelop::AbstractContextBuilder::contextStack () const
Audit whether access to the context stack is still required, and provide replacement functionality if possible.

Member KDevelop::AbstractContextBuilder::nextContextIndex ()

further delineate the role of this function and rename / document better.

make private again?

Member KDevelop::AbstractNavigationWidget::embeddedWidgetRight ()
Do this through a public interface post 4.2

Class KDevelop::AbstractType
)
  • Register the type in a source-file using REGISTER_TYPE(..),

Member KDevelop::AbstractTypeBuilder::openTypeFromName (QualifiedIdentifier id, T *typeNode, bool needClass)

only functions may have multiple declarations here

What about position?

Member KDevelop::AbstractTypeFactory::copy (const AbstractTypeData &from, AbstractTypeData &to, bool constant) const =0
David, please check this

Member KDevelop::AbstractUseBuilder::newUse (T *node, const SimpleRange &newRange, Declaration *declaration)

This can cause I/O, so it would be better if it was possible with only a read-lock

Work this over! We must not pass around "Declaration*" values if the duchain is not locked.

Don't call findDeclarations during write-lock, it can lead to UI lockups

Member KDevelop::commentRepository ("Comment Repository")
Use reference counting

Member KDevelop::Declaration::allocateOwnIndex ()
Fix multithreading stuff with template instantiation, preferably using some internal mutexes

Member KDevelop::Declaration::isTypeAlias () const
see whether it would be useful to create an own TypeAliasDeclaration sub-class for this

Member KDevelop::Declaration::setContext (DUContext *context, bool anonymous=false)
re-enable. In C++ support we need a short window to put visible declarations into template contexts

Member KDevelop::Declaration::uses () const
The following two are convenience-functions. Think whether they should stay here, or be moved out.

Member KDevelop::DeclarationId::getDeclaration (const TopDUContext *context) const
think this over once we don't pull in all imported top-context any more

Member KDevelop::DeclarationId::getDeclarations (const TopDUContext *context) const
think this over once we don't pull in all imported top-context any more

Member KDevelop::DECLARE_LIST_MEMBER_HASH (DUContextData, m_uses, Use) class DUContextData

Create an additional structure for importing to/from "temporary" contexts and classes in a way that it persists while saving/loading, and doesn't require changing a top-contexts data only because a class was derived from.

remove

remove

Member KDevelop::DUChain::waitForUpdate (const IndexedString &document, TopDUContext::Features minFeatures, bool wantProxyContext=false)
When we don't do this, the backgroundparser doesn't process anything. The background-parser should be moved into an own thread, so we wouldn't need to do this.

Member KDevelop::DUChainLock::releaseReadLock ()
Remove the all readers that do not exist any more at some point(leave other readers there with recursion 0 because it is very probable that they will lock again, and not having to re-allocate the bucket might speed up the locking.

Class KDevelop::DUChainObserver
change name to DUChainNotifier ?

Class KDevelop::DUContext
change child relationships to a linked list within the context?

Member KDevelop::DUContext::createUse (int declarationIndex, const SimpleRange &range, KTextEditor::SmartRange *smartRange, int insertBefore=-1)
do binary search

Member KDevelop::DUContext::DeclarationList
Should be protected, moved here temporarily until I have figured out why the gcc 4.1.3 fails in cppducontext.h:212, which should work (within kdevelop) Declaration search implementation

Member KDevelop::DUContext::findContextsInternal (ContextType contextType, const SearchItem::PtrList &identifiers, const SimpleCursor &position, QList< DUContext * > &ret, const TopDUContext *source, SearchFlags flags=NoSearchFlags) const
This doesn't seem quite correct: Local Contexts aren't found anywhere Step 1: Apply namespace-aliases and -imports

Member KDevelop::DUContext::findLocalDeclarationsInternal (const Identifier &identifier, const SimpleCursor &position, const AbstractType::Ptr &dataType, DeclarationList &ret, const TopDUContext *source, SearchFlags flags) const

This is C++-specific

Eventually do efficient iteration-free filtering

Member KDevelop::DUContext::mergeDeclarationsInternal (QList< QPair< Declaration *, int > > &definitions, const SimpleCursor &position, QHash< const DUContext *, bool > &hadContexts, const TopDUContext *source, bool searchInParents=true, int currentDepth=0) const
this is language-dependent)

Member KDevelop::DUContext::SearchItem::SearchItem (const QualifiedIdentifier &id, Ptr nextItem=Ptr(), int start=0)
find out why this KDevVarLengthArray crashes when it's resized!

Member KDevelop::DUContextDynamicData::addChildContext (DUContext *context)
Do binary search to find the position

Member KDevelop::DUContextDynamicData::addDeclaration (Declaration *declaration)
Do binary search to find the position

Member KDevelop::DUContextDynamicData::needsLocalDeclarationsHash ()
Do this again, it brings a large performance boost

Member KDevelop::DumpDotGraph::dotGraph (KDevelop::DUContext *context, bool shortened=false)
maybe get this as a parameter

Member KDevelop::escapeForBracketMatching (QString str)
this hackery sucks

Member KDevelop::featuresMatch (ParsingEnvironmentFilePointer file, TopDUContext::Features minimumFeatures, QSet< ParsingEnvironmentFilePointer > &checked)
Before recursing, do a fast check whether one of the imports has special rules stored. Else it's not neede.

Member KDevelop::FunctionDefinition::definition (const Declaration *decl)
Find better ways of deciding which definition to use

Member KDevelop::FunctionType::arguments () const
Don't do the conversion

Member KDevelop::FunctionType::removeArgument (AbstractType::Ptr argument)
this function doesn't seem to be used, remove it?

Class KDevelop::IndexedDeclarationHandler
move into own header

Member KDevelop::ItemRepository::deleteItem (unsigned int index)
Clear the nextBucketForHash links when not needed any more, by doing setNextBucketForHash(hash, 0);

Member KDevelop::ItemRepository::index (const ItemRequest &request)
Move this compound statement into an own function

Member KDevelop::ItemRepositoryRegistry::open (const QString &path, bool clear=false, KLockFile::Ptr lock=KLockFilePtr())
Ask the user

Member KDevelop::processExists (int pid)
Find a cross-platform way of doing this!

Member KDevelop::QualifiedIdentifier::explicitlyGlobal () const
Remove this flag

Member KDevelop::rStrip (const QByteArray &str, QByteArray &from)
Check whether this can cause problems in utf-8, as only one real character is treated!

Member KDevelop::strip (const QByteArray &str, QByteArray &from)
Check whether this can cause problems in utf-8, as only one real character is treated!

Class KDevelop::TopDUContext

move the registration with DUChain here

Member KDevelop::TopDUContext::applyAliases (const AliasChainElement *backPointer, const SearchItem::Ptr &identifier, Acceptor &acceptor, const SimpleCursor &position, bool canBeNamespace, ApplyAliasesBuddyInfo *buddy, uint recursionDepth) const

Implement a cache so at least the global import checks don't need to be done repeatedly. The cache should be thread-local, using DUChainPointer for the hashed items, and when an item was deleted, it should be discarded

explicitlyGlobal if the first identifier los global

check iso c++ if using-directives should be respected on top-level when explicitly global

this is bad for a very big repository(the chains should be walked for the top-context instead)

Member KDevelop::TopDUContext::ast () const
Figure out logic to get rid of AST when it is not needed/useful

Member KDevelop::TopDUContext::Cache::Cache (TopDUContextPointer context)
move this kind of caching into the symbol-table

Class KDevelop::TopDUContext::DeclarationChecker
move data to private d pointer classes

Member KDevelop::TopDUContext::deleting () const
remove d_func()->m_deleting, not used any more

Member KDevelop::TopDUContext::indexForUsedDeclaration (Declaration *declaration, bool create=true)
Make m_usedDeclarationIds sorted, and find the decl. using binary search

Member KDevelop::TopDUContext::isOnDisk () const
Change this to releasingToDisk, and only enable it while saving a top-context to disk.

Member KDevelop::TopDUContext::TopDUContext (TopDUContext *shareDataFrom, ParsingEnvironmentFile *file=0)
this is incompatible with data-sharing, remove that option again.

Member KDevelop::TopDUContextDynamicData::load (uint topContextIndex)
Load the language if it isn't loaded yet, problem: We're possibly not in the foreground thread!

Member KDevelop::TopDUContextDynamicData::store ()

Save the meta-data into a repository, and only the actual content data into a file. This will make saving+loading more efficient, and will reduce the disk-usage. Then we also won't need to load the data if only the meta-data changed.

If we split up data and metadata, we don't need to do this

Member KDevelop::UsesCollector::startCollecting ()

Fail!

more intelligent

Page Using already created Definition-Use Chains in plugins

include a note on how to request loading of contexts from disk, and requesting parsing of files which are not currently in the duchain.

keep the AST in memory for loaded files

add mechanism to get at the AST

language/duchain

Skip menu "language/duchain"
  • Main Page
  • Namespace List
  • Class Hierarchy
  • Alphabetical List
  • Class List
  • File List
  • Namespace Members
  • Class Members
  • Related Pages

KDevelop Platform Libraries

Skip menu "KDevelop Platform Libraries"
  • interfaces
  • language
  •   codegen
  •   duchain
  •   editor
  • outputview
  • project
  • shell
  • sublime
  • util
  • vcs
Generated for KDevelop Platform Libraries by doxygen 1.5.9-20090814
This website is maintained by Adriaan de Groot and Allen Winter.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V. | Legal