Store modification times in Declaration Data class?

[Sven Brauch]

Hi David,

thanks for your response.
I imagined this to work like this: As soon as a file is parsed, it
throws all its type hints at all relevant declarations. Those stay
valid until the file is re-parsed; if it's re-parsed, it just creates
*new* type hints, which then are valid instead of the old ones. The
old ones will then be invalidated by comparing their creation time
with the current modification revision of the file, and noticing that
they're old. However, I don't know how much performance that would
eat.

Still, your approach is probably more elegant. I'm just not entirely
sure if a type-hint can be bound to a specific use in all cases; it
*might* be a more complex expression. However, for the basic
function-argument hints I want to implement now I think that should
work.
I didn't exactly understand how your example works, tough... I do not
want to delete declarations if uses go away, I want to store a list of
types for a declaration which are deleted if their "uses" go away. How
is that to be realized with your example?

Greetings,
Sven

2011/7/4 David Nolden <zwabel at googlemail.com>:
> 2011/7/1 Sven Brauch <svenbrauch at googlemail.com>:
>> Hi!
>>
>> I'm trying to create a Declaration type named "TypeHintedDeclaration",
>> which allows adding type hints to it, which will then be used for
>> setting a type to the declaration if it is encountered on re-parsing
>> (I hope that doesn't sound completely insane).
>>
>> However, those type hints cannot stay with the declaration forever,
>> they need to be deleted when the -- whatever it might be, line of code
>> -- which created them is changed or removed. Thus I wanted to do the
>> following: Along with the type, also store the (indexed) TopContext
>> the type was created from and that TopContexts current
>> modificationRevision in the data class. Then, when accessing the type
>> hints, delete everything for which the modification revision does not
>> match the current modification revision of the file.
>>
>> Do you think that can work? How would I store the modification
>> revisions -- the APPENDED_LIST macros give me strange errors, because
>> the ModificationRevision class apparently isn't meant to be stored
>> there?
>
> It should work, it is safe to store ModificationRevision into the
> duchain directly. To use the APPENDED_LIST stuff, you have to call all
> the right functions in the right places (in the copy-constructor,
> constructors, etc.). Take a look at ClassDeclarationData for an
> example.
>
> However, I cannot really see how the ModificationRevision alone would
> help you here. It doesn't tell whether the use which created the
> "type-hint" still exists, it just tells you whether the parsing-state
> of the file is up-to-date.
>
> The types should rather be conditioned on actual _uses_, eg. {
> IndexedDUContext context; int use; } or similar. See the draft I just
> pushed, named "useconditioneddeclaration.h", we should finish this,
> and also add a "useconditionedtype.h" (maybe based on UnsureType).
>
> Greetings, David
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>