patch to do away with caching of __CFConstantStringClassReference

[jahanian]

Here is the patch.

		

On Apr 15, 2013, at 1:36 PM, jahanian <fjahanian at apple.com> wrote:

> This is // rdar://13598026
> We cache uses of __CFConstantStringClassReference external symbol when generating the API for
> cfstring. This, however, causes a crash in extreme rare case where user has chosen to provide a tentative
> definition of __CFConstantStringClassReference followed by build of a cfstring followed by delayed
> generation of another cfstring. This sequence of events causes the 2nd access to this cached symbol to be
> a dangling reference because in the course of completing the tentative definition, the cached __CFConstantStringClassReference
> has been erased. I fix this by removing caching of __CFConstantStringClassReference altogether. This is because
> all global symbols are cached in llvm’s global symbol table which is tightly managed. There is no need to have our own
> cache of this symbol. 
> Please review.
> 
> - Fariborz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130415/57a698f3/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130415/57a698f3/attachment.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130415/57a698f3/attachment-0001.html>