[cfe-commits] r58100 - in /cfe/trunk: lib/Sema/SemaDecl.cpp test/SemaCXX/fntype-decl.cpp

[Ted Kremenek]

On Oct 27, 2008, at 6:40 AM, Doug Gregor wrote:

> I don't think the ownership policy would necessarily clear this up.
> For ownership to solve this problem, we would need to have the
> FunctionDecl "own" the TypedefDecl that is used to express it's type.

Thanks for the clarification.  I'm not certain if you saw the  
discussion a month or so ago about DeclGroups and TypeSpecifiers,  
which would hopefully resolve many (most?) of these kind of ownership  
issues in the ASTs.

> It can't have sole ownership, of course, since another FunctionDecl
> might use it as the type.

There is a difference between the ownership of the decl and referring  
to a type.

DeclGroups/TypeSpecifiers are intended to enforce the following:

(a) Types don't own Decls (the biggest chunk missing)
(b) Decls don't own Types (already in place; ASTContext owns Types)

> There are a few solutions here. One easy option, which I've committed
> already as a band-aid, is as Argiris said: destroy the decls in
> reverse order. Since a Decl should only depend on Decls before it,
> this works.

Make sense.

> Another alternative is to ban destructors that look
> through any non-owned pointer;

That's the solution I imagined all along, and makes the most amount of  
sense when you consider clients of the ASTs that may modify them in  
place (and arbitrarily delete and create nodes).

> for example, this would mean that
> FunctionDecl would have to have its own NumParams field rather than
> looking through its type field to find the number of parameters. Then,
> order of destruction would never matter.

  Since Decls shouldn't own Types, this particular example shouldn't  
actually be an issue.  Are you seeing this to be a problem?  Clearly  
this means that Types should be destroyed after Decls are, but Types  
are released when ASTContext is destroyed (which in TranslationUnit,  
occurs after the Decls are released).