[PATCH] shared dpointer for duchain

[David Nolden]

On Monday 17 December 2007 00:28:16 Andreas Pakulat wrote:
> And another problem: Declaration::setContext(). When doing setContext
> before setRange I get a crash from setContext. If doing setContext after
> setRange in the leaf classes only then I get an assertion from
> ENSURE_CAN_WRITE in setContext.

Hmm I don't understand why you get the crash, at least in the current code 
there is no connection between setContext and setRange.
Ensure_can_write only triggers an assertion when there already was a context 
set earlier. In the case of instantiated template declarations, I think 
setContext is called only exactly once, so this assertion should not trigger. 
Also the order of things during template instantiation is quite fragile, 
because there is only one precise window where a declaration can be changed 
without the du-chain being write locked. So it's important that the order of 
things is not changed.

> Now I'm wondering wether it might make sense to simply copy the context
> pointer inside the dpointer copy constructor or wether setContext does
> additional things which need to be done for the new copy.

Maybe the reason for the assertion is that you already copy that context? The 
logic that happens while cloning needs to stay exactly as it is, which 
especially means that the context of a cloned declaration is zero after 
cloning. The reason for that is that we can clone objects while the duchain 
is not write locked, so we cannot simply add the declaration into a context. 
Instead, the declaration has a zero context after copying, and is 
moved "anonymously" into the context. And this is exactly where your 
assertion seems to happen, probably because there is already a context set 
after cloning.


> Same question about the definition pointer of a declaration. Can that
> pointer be just copied from the rhs-dpointer as well?

Because a declaration and definition usually have a strict 1-1 relationship, a 
clone should have no declaration set at all(so zero). This is also how it's 
done now. It's best to exactly resembe all these behaviors from the current 
code, after all it's working, and it's a fragile structure.

greetings, David