aboutsummaryrefslogtreecommitdiff
path: root/lldb/packages/Python/lldbsuite/test/configuration.py
diff options
context:
space:
mode:
authorErik Pilkington <erik.pilkington@gmail.com>2018-10-12 17:22:10 +0000
committerErik Pilkington <erik.pilkington@gmail.com>2018-10-12 17:22:10 +0000
commit92d8a29ca0d506cea28718644527c4711ee3e694 (patch)
treebc12494cc31b7eaba6255a3e80b3460c60520e40 /lldb/packages/Python/lldbsuite/test/configuration.py
parent727891c9182aabd39cef9998ab7be365cb5ab19b (diff)
downloadllvm-92d8a29ca0d506cea28718644527c4711ee3e694.zip
llvm-92d8a29ca0d506cea28718644527c4711ee3e694.tar.gz
llvm-92d8a29ca0d506cea28718644527c4711ee3e694.tar.bz2
[CodeGen] Handle extern references to OBJC_CLASS_$_*
Some ObjC users declare a extern variable named OBJC_CLASS_$_Foo, then use it's address as a Class. I.e., one could define isInstanceOfF: BOOL isInstanceOfF(id c) { extern void OBJC_CLASS_$_F; return [c class] == (Class)&OBJC_CLASS_$_F; } This leads to asserts in clang CodeGen if there is an @implementation of F in the same TU as an instance of this pattern, because CodeGen assumes that a variable named OBJC_CLASS_$_* has the right type. This commit fixes the problem by RAUWing the old (incorrectly typed) global with a new global, then removing the old global. rdar://45077269 Differential revision: https://reviews.llvm.org/D53154 llvm-svn: 344373
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/configuration.py')
0 files changed, 0 insertions, 0 deletions