From b6e048c6e516df5abc4be323349b5f7d15c08ede Mon Sep 17 00:00:00 2001
From: David Blaikie <dblaikie@gmail.com>
Date: Tue, 1 Feb 2022 16:15:25 -0800
Subject: [PATCH] Test fixes for prior patch

---
 llvm/test/DebugInfo/X86/tu-to-non-tu.ll | 61 +++++++++++++++++--------
 1 file changed, 42 insertions(+), 19 deletions(-)

diff --git a/llvm/test/DebugInfo/X86/tu-to-non-tu.ll b/llvm/test/DebugInfo/X86/tu-to-non-tu.ll
index 4b8ea04bedc5..6702b330a1dc 100644
--- a/llvm/test/DebugInfo/X86/tu-to-non-tu.ll
+++ b/llvm/test/DebugInfo/X86/tu-to-non-tu.ll
@@ -1,17 +1,41 @@
 ; RUN: llc -filetype=obj -O0 -generate-type-units -mtriple=x86_64-unknown-linux-gnu < %s \
 ; RUN:     | llvm-dwarfdump -debug-info -debug-types - | FileCheck %s
 
-; Test that a type unit referencing a non-type unit (in this case, it's
-; bordering on an ODR violation - a type with linkage references a type without
-; linkage, so there's no way for the first type to be defined in more than one
-; translation unit, so there's no need for it to be in a type unit - but this
-; is quirky/rare and an easy way to test a broader issue). The type unit should
-; not end up with a whole definition of the referenced type - instead it should
-; have a declaration of the type, while the definition remains in the primary
-; CU.
-; (again, arguably in this instance - since the type is only referenced once, it
-; could go in the TU only - but that requires tracking usage & then deciding
-; where to put types, which isn't worthwhile right now)
+; Test that a type unit referencing a non-type unit produces a declaration of
+; the referent in the referee.
+
+; This test was intended to test this:
+
+; * Also check that an attempt to reference an internal linkage (defined in an anonymous
+; * namespace) type from a type unit (could happen with a pimpl idiom, for instance -
+; * it does mean the linkage-having type can only be defined in one translation
+; * unit anyway) forces the referent to not be placed in a type unit (because the
+; * declaration of the internal linkage type would be ambiguous/wouldn't allow a
+; * consumer to find the definition with certainty)
+
+; But the implementation was buggy, so for now, it's reverted but still test covered.
+; A buggy input/case looks like this:
+;  namespace {
+;  template <typename> struct a {};
+;  } // namespace
+;  class c {
+;    c();
+;  };
+;  class b {
+;    b();
+;    a<c> ax;
+;  };
+;  b::b() {}
+;  c::c() {}
+
+; I haven't bothered adding a test case for this ^ to avoid regression, as
+; likely we'll move in a different direction entirely, since this approach is
+; incomplete anyway. Specifically it looks like we want a flag on DICompositeType
+; to indicate whether it should go in a type unit - the current frontend strategy
+; of omitting the 'identifier' field is inadequate (since it breaks LLVM IR linking
+; type resolution - leaving a separate decl/def of the same type), so if we fix that
+; we can fix the internal-referencing issue by using such a flag instead of trying
+; to figure it out in the backend.
 
 ; Built from the following source, compiled with this command:
 ; $ clang++-tot decl.cpp -g -fdebug-types-section -c
@@ -83,6 +107,13 @@
 ; CHECK-NOT: DW_TAG
 ; CHECK: DW_AT_name {{.*}}"tu_ref_non_tu"
 
+; CHECK-LABEL: Type Unit:
+; CHECK: DW_TAG_structure_type
+; CHECK-NOT: DW_TAG
+; CHECK: DW_AT_name {{.*}}"ref_internal"
+; CHECK-NOT: DW_TAG
+; CHECK: DW_AT_byte_size
+
 ; CHECK-LABEL: Type Unit:
 ; CHECK: DW_TAG_structure_type
 ; CHECK-NOT: DW_TAG
@@ -120,19 +151,11 @@
 ; CHECK-NEXT:   DW_AT_declaration       (true)
 ; CHECK-NEXT:   DW_AT_signature (0xb1cde890d320f5c2)
 
-; CHECK: DW_TAG_namespace
-; CHECK-NOT: {{DW_AT_name|DW_TAG}}
 ; CHECK: DW_TAG_structure_type
 ; CHECK-NOT: DW_TAG
 ; CHECK: DW_AT_name {{.*}}"non_tu"
 
 
-; CHECK: DW_TAG_structure_type
-; CHECK-NOT: DW_TAG
-; CHECK: DW_AT_name {{.*}}"ref_internal"
-; CHECK-NOT: DW_TAG
-; CHECK: DW_AT_byte_size
-
 ; CHECK: DW_TAG_namespace
 ; CHECK-NOT: {{DW_TAG|DW_AT}}
 ; CHECK: DW_TAG_structure_type
-- 
2.35.1.723.g4982287a31-goog