[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