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). _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
