[lldb] Check if resolved typelias is a typealias when canonicalizing

[augusto2112]

A swift typealias may resolve to a clang typealias, which we must then
resolve.

[adrian-prantl]

Could you add some sanity-check to avoid an infinite loop here if the typedefs end up being circular? Either a DenseSet of visited nodes or just a max_depth counter?

[adrian-prantl]

maybe:

diff --git a/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.cpp b/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.cpp
index f651879a6e9d..2e7b3528c083 100644
--- a/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.cpp
+++ b/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.cpp
@@ -393,7 +393,12 @@ static std::pair<swift::Demangle::NodePointer, CompilerType>
 ResolveTypeAlias(SwiftASTContext *module_holder,
                  swift::Demangle::Demangler &dem,
                  swift::Demangle::NodePointer node,
-                 bool prefer_clang_types = false) {
+                 bool prefer_clang_types = false,
+                 unsigned char iter = 0) {
+  if (iter > 99)
+    LLDB_LOGF(GetLogIfAllCategoriesSet(LIBLLDB_LOG_TYPES),
+              "suspiciously long type alias chain, giving up");
+    return {{}, {}};
   LLDB_SCOPED_TIMER();
   auto resolve_clang_type = [&]() -> CompilerType {
     auto maybe_module_and_type_names = GetNominal(dem, node);
@@ -481,6 +486,10 @@ ResolveTypeAlias(SwiftASTContext *module_holder,
              "Unrecognized demangling %s", desugared_name.AsCString());
     return {{}, {}};
   }
+  // Resolve type aliases that are type aliases.
+  if (n->getKind() == Node::Kind::TypeAlias)
+    return ResolveTypeAlias(module_holder, dem, n, prefer_clang_types,
+                            iter + 1);
   return {n, {}};
 }

For some reason this alternative patch seems to introduce a ton of new test failures.

[augusto2112]

Do you mean the patch as-is is causing test failures?

[adrian-prantl]

When I applied my alternate patch I posted above yesterday it introduced a bunch of new test failure. Either means my patch has a bug, or it has unintended consequences because it run on every ResolveTypeAlias invocations. (Yours is more targeted).