Associating a clean .kdevduchain repo for unit tests

[David Nolden]

Am Montag 31 August 2009 21:13:57 schrieb Milian Wolff:
> David Nolden, 31.08.2009:
> > Am Montag 31 August 2009 13:19:22 schrieb Milian Wolff:
> > > David Nolden, 31.08.2009:
> > > > Am Mittwoch 26 August 2009 12:41:36 schrieb Milian Wolff:
> > > > > PHP has the problem that it requires a clean .kdevduchain for unit
> > > > > tests. And I'd say it would make sense for other languages as well
> > > > > to always operate on a clean .kdevduchain repo in unit tests.
> > > > >
> > > > > Is there any way we can enfore a kdevduchain repo for unit tests?
> > > > > Giving it a name like the INT_MAX value or something would make it
> > > > > _very_ unlikely that it ever gets an existing repo.
> > > > >
> > > > > Oh and before I forget it: Unit tests can disable _writing_ to a
> > > > > repo (very good!), but not disable _reading_ from a repo.
> > > > > See:
> > > > >      DUChain::self()->disablePersistentStorage();
> > > >
> > > > Maybe the simplest and cleanest solution would be also disabling the
> > > > _loading_ of a repository when persistent storage is disabled.
> > >
> > > But that is currently not implemented, right?
> >
> > Yes, it's not yet implemented.
>
> If I should implement that, I would appreciate some help:
>
> a) should I just use thes dDUChainPrivate->m_cleanupDisabled, or should it
> be renamed then (imo it should)
> b) but disablePersistentStorage is imo a good name, i.e. can stay
> c) is returning 0 in the chainForDocument method(s) enough? It would be for
> PHP afaik, since that is what we check in the parsejob... But I'm unsure on
> whether that is the correct thing to do, since then a unit test like that:
> - create duchain for some url
> - create second duchain for another url, which e.g. includes another one by
> url => we'd need chainForDocument to return the just created duchain (but
> none that is stored on disk...)
>
> Looking at chainForDocument with IndexedString arg, I see a comment:
>
>     return list[0]->topContext(); //Load a top-context if there is none in
> memory
>
> Is that the only thing we have to omit when disabling persistent storage?

Thinking of it again, it has to be done in a different way than 
disablePersistentStorage.

There is also the global item-repositories, and those are loaded right at 
startup in static constructors, and can not be prevented by any function-call 
like "DUChain::disablePersistentStorage".

So, the overall better solution is:

In itemrepository.cpp:
Check "#ifdef DUCHAIN_DISABLE_PERSISTENT_STORAGE", and if it is set:
- always pick a repository-number that either does not exist, or that has to 
be cleared
-  Do not write a version-hint into the repository, so it is always considered 
invalid and will be cleared at some point

And in all tests that require it, just add "-
DDUCHAIN_DISABLE_PERSISTENT_STORAGE" through cmake.

This will also be useful for other tools that might use the duchain but don't 
want persistent storage, for example "duchaintokross".

Greetings, David