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

[Doug Gregor]

On Mon, Oct 27, 2008 at 10:42 AM, Ted Kremenek <kremenek at apple.com> wrote:
>
> On Oct 27, 2008, at 7:34 AM, Ted Kremenek wrote:
>
> 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).
>
> Doug just kindly pointed me to an example where Types can depend on Decls to
> implement basic functionality.
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081020/008535.html
> I now recall that this occurs in several places (such as in the Objective-C
> ASTs), but they don't always appear to create ownership issues.
> I'm not quite certain what is the best solution for this.

For FunctionDecl, it's easy: add a NumParams field that tracks the
number of parameters, so that the FunctionDecl destructor does not
need to look into the type of the function. I don't know where in
Objective-C land we have this same issue, although
TranslationUnit::~TranslationUnit has some scary code in it that
involves destruction of Objective-C Decls.

  - Doug