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

[Rafael Espíndola]

> 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?

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: text/x-patch
Size: 4922 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150122/138e7b34/attachment.bin>