[PATCH]: store a range as position for a context import instead of a cursor

David Nolden david.nolden.kdevelop at art-master.de
Sat Aug 8 19:58:00 UTC 2009


Am Samstag 08 August 2009 15:12:08 schrieb Milian Wolff:
> David, please review.
>
> Others: How do I update the kross stuff? Since I changed the kdevplatform
> API
>
> Language-Plugin-Maintainer: you have to update your plugins and change the
> calls to addImportedParentContext and pass a range instead of a cursor. In
> cpp for example I pass the range between "" or <>.
>
> With my upcomming patch which will push the whole includewidget and other
> stuff into kdevplatform it will be much easier to find the positions where
> to show these widgets. You won't have to do string-comparison. Just compare
> the ranges of the imports for the current file with the positoin of the
> current cursor.
Just btw.: String-comparison is very easy to do, so it doesn't necessarily 
have to be easier this way.

I've taken a look at the patch and the basic issue again, but there is one 
thing that I unfortunately forgot to think of when we first talked about the 
issue: The class DUContext::Import is very critical for the overall size of 
the duchain data, and needs to be kept as small as possible. When we talked 
about it I thought that the cursor/range was only stored for top-context 
imports, but that's not the case these days.

Adding a SimpleRange instead of the SimpleCursor increases the size by 50%, so 
I fear we cannot do it this way.

Even the SimpleCursor that was already there 
is already too much, as it isn't needed in 99% of the cases, and we need a way 
of associating additional data to imports, without blowing up the minimum 
required size.

The most correct way of doing this would be allowing a direct association 
between a use and an import, and building a use that contains the range for 
such imports. But that raises the problem that uses don't have global 
identities within their top-context yet, and the whole concept might need some 
work, especially in the C++ support.

From a logical point of view, a cursor for an import should actually be 
enough. The basic idea behind that cursor is, that from that point on, the 
import is 'effective'. For example in C++, the content of #included files are 
only visible behind the #include directive, so the position of the directive 
is marked in the import, and is used during visibility checks.

The range is a more detailed information similar to uses, which is not needed 
in most cases, and thus should not be stored on a general basis, but only in 
specific cases when required.

Greetings, David





More information about the KDevelop-devel mailing list