Removed the assertion that we can find any named

Objective-C type in the runtime.  This is not actually
true, it's entirely possible to say

@class DoesntExist;

@interface DoesExist {
  DoesntExist *whyyyyy;
}
@end

and this code will not only compile but also run.  So
this assertion will fire in situations users might
encounter.

I left the assertion enabled in debug mode, because we
could still catch a case we're not aware of (i.e., a
class that we *ought* to have found but where somehow
we mis-parsed the name).

<rdar://problem/19151914>

llvm-svn: 224038

1 files changed, 8 insertions, 1 deletions

diff --git a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
index 197bdc01fcf..57d6d548965 100644
--- a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
+++ b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
@@ -253,7 +253,14 @@ AppleObjCTypeEncodingParser::BuildObjCObjectPointerType (clang::ASTContext &ast_
                                                     max_matches,
                                                     decls);
 
-        assert(num_types); // how can a type be mentioned in runtime type signatures and not be in the runtime?
+        // The user can forward-declare something that has no definition.  The runtime doesn't prohibit this at all.
+        // This is a rare and very weird case.  We keep this assert in debug builds so we catch other weird cases.
+#ifdef LLDB_CONFIGURATION_DEBUG
+        assert(num_types);
+#else
+        if (!num_types)
+            return ast_ctx.getObjCIdType();
+#endif
         
         return ClangASTContext::GetTypeForDecl(decls[0]).GetPointerType().GetQualType();
     }