[patch][pr22293] Don't crash during codegen of a recursive destructor

[John McCall]

> On Jan 22, 2015, at 7:53 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> Yuck. How expensive is a TrackingVH? Since we're moving towards having
>> lots of DeferredGlobals, do we need to worry about this?
> 
> It is a hash table lookup on rauw.
> 
> When we return false from MayBeEmittedEagerly, we add entries where
> GV is null. The only reason we ever store a GV is to save on duplicated lookups
> of the mangled name during the emission of deferred decls.
> 
> If we were to deffer all, I think we could probably avoid even computing mangled
> names before EOF. Just remember all the GD in a plain vector. At EOF,
> mangle each and
> 
> * If required: output:
> * It GV already created, it was used: output.
> * Else, set DeferredDecls[MangledName] in case we find a use.
> 
>> If you think the cost is fine, then this LGTM; otherwise, I suppose
>> we'll need to find another approach.
> 
> Attached is a second patch (on top of the first one) that just removes GV
> from the delay list. This trades not needing a TrackingVH for a second
> looked by the mangled name. This is probably on the correct path if we
> are going to delay more. Otherwise a TrackingVH is probably cheaper
> as RAUW is not that common in clang. What do you think?

I think the TrackingVH is fine.

John.