Recompiling contexts

David Nolden david.nolden.kdevelop at
Fri Sep 2 09:56:26 UTC 2011

2011/8/25 Sven Brauch <svenbrauch at>:
> Hi!
> I got a problem with contexts being cleaned when recompiling. The
> exact situation is this: Assume a function declaration with an
> aguments context. If I insert a line before the function declaration,
> everything is fine; however, when I remove that line again, the
> arguments context is deleted, apparently because it can't be found at
> the position where it is expected (for what I understood, the search
> starts beginning from the old starting point). This causes problems,
> because all the declarations in the context are being re-created then,
> and I'd need them to be persistent.
> It is bugging me how this is supposed to work. I assumed that magic
> RangeInRevision stuff would transform the old context range to the new
> one, so it can again be found at the same place. However, the new
> modification revision for the context is set after the duchain
> analysis is already done, so I don't see how that could work...
> The comments for openContext also say something about contexts being
> found by their scopeIdentifier, however if I set one for the arguments
> context that doesn't solve the problem. I also would not know what
> identifier to use for that context (I tried <function name> +
> __arguments for testing this, but that's not really an acceptable
> solution).
> I'm just getting quite confused about this and it would be cool if
> someone could tell me how it's supposed to work. Maybe I'm also using
> the RangeInRevision "API" in a wrong way?

You shouldn't do range transformation at all, because all that is
automatically done by the parse-job on a higher level. If you want to
know why the context isn't matched, you should try to debug
AbstractContextBuilder::openContextInternal, and see which of the
matching-conditions is mismatched.

For unnamed contexts only a range-comparison is done there.

Maybe you have a problem with the order in which you create the
contexts, because the updating code expects the order to always be the
same (make sure that the order always equals the range-order).

Greetings, David

More information about the KDevelop-devel mailing list