Fix a marvelous chained AST writing bug, where we end up with the
following amusing sequence:
- AST writing schedules writing a type X* that it had never seen
before
- AST writing starts writing another declaration, ends up
deserializing X* from a prior AST file. Now we have two type IDs for
the same type!
- AST writer tries to write X*. It only has the lower-numbered ID
from the the prior AST file, so references to the higher-numbered ID
that was scheduled for writing go off into lalaland.
To fix this, keep the higher-numbered ID so we end up writing the type
twice. Since this issue occurs so rarely, and type records are
generally rather small, I deemed this better than the alternative: to
keep a separate mapping from the higher-numbered IDs to the
lower-numbered IDs, which we would end up having to check whenever we
want to deserialize any type.
Fixes <rdar://problem/8511624>, I think.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@115647 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/test/PCH/chain-remap-types.m b/test/PCH/chain-remap-types.m
new file mode 100644
index 0000000..a45a79d
--- /dev/null
+++ b/test/PCH/chain-remap-types.m
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -emit-pch -x objective-c-header -o %t1 %S/Inputs/chain-remap-types1.h
+// RUN: %clang_cc1 -emit-pch -x objective-c-header -o %t2 %S/Inputs/chain-remap-types2.h -include-pch %t1 -chained-pch
+// RUN: %clang_cc1 -include-pch %t2 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -ast-print -include-pch %t2 %s | FileCheck %s
+
+// CHECK: @class X;
+// CHECK: struct Y
+// CHECK: @property ( assign,readwrite ) X * prop
+// CHECK: void h(X *);
+// CHECK: @interface X(Blah)
+// CHECK: void g(X *);
+