[Lldb-commits] [lldb] [lldb] handle existing ClassTemplateSpecializationDecl gracefully (PR #207705)

Michael Buch via lldb-commits lldb-commits at lists.llvm.org
Mon Jul 6 05:13:39 PDT 2026


================
@@ -1882,22 +1882,27 @@ TypeSP DWARFASTParserClang::ParseStructureLikeDIE(
         m_ast.CreateClassTemplateSpecializationDecl(
             containing_decl_ctx, GetOwningClangModule(die), class_template_decl,
             tag_decl_kind, template_param_infos);
-    if (!class_specialization_decl) {
-      if (log) {
-        dwarf->GetObjectFile()->GetModule()->LogMessage(
-            log,
-            "SymbolFileDWARF({0:p}) - Failed to create specialization for "
-            "clang::ClassTemplateDecl({1}, {2:p}).",
-            this, llvm::StringRef(attrs.name), class_template_decl);
-      }
-      return TypeSP();
+    if (class_specialization_decl) {
+      clang_type =
+          m_ast.CreateClassTemplateSpecializationType(class_specialization_decl);
+
+      m_ast.SetMetadata(class_template_decl, metadata);
+      m_ast.SetMetadata(class_specialization_decl, metadata);
+    } else if (log) {
+      // A specialization with identical template arguments already exists.
+      // This happens with malformed/duplicated DWARF, e.g. GCC emits several
+      // reduced copies of a std::tuple<...> instantiation whose only template
+      // child is an empty DW_TAG_GNU_template_parameter_pack, so every copy
+      // collapses to the same (empty) argument list. Failing to parse the type
+      // here would leave members that reference it (such as unique_ptr's _M_t)
+      // with a null type and crash data formatters. Instead, fall through and
+      // build a plain (non-template) record type below.
----------------
Michael137 wrote:

> A specialization with identical template arguments already exists.

`class_specialization_decl == nullptr` doesn't necessarily imply that there is a duplicate specialization.

It's true based on the implementation, but it's not an obvious signal when reading this code and also may change in the future. E.g., nullptr could just be a different error condition. Probably best to signal the "there is an existing specialization" differently then just returning nullptr. We should've thought of that as part of https://github.com/llvm/llvm-project/commit/4dfe212dade7

Also, could you explain why with a `class_specialization_decl == nullptr` its fine to skip `CreateClassTemplateSpecializationType` and continue with the rest of this function? That seems like it would cause more trouble.

https://github.com/llvm/llvm-project/pull/207705


More information about the lldb-commits mailing list