[ExpressionParser] Re-implement r327356 in a less disruptive way.

Instead of applying the sledgehammer of refusing to insert any
C++ symbol in the ASTContext, try to validate the decl if what
we have is an operator. There was other code in lldb which was
responsible for this, just not really exposed (or used) in this
codepath. Also, add a better/more comprehensive test.

<rdar://problem/35645893>

llvm-svn: 328025

1 files changed, 0 insertions, 9 deletions

diff --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
index 093be6c898a..07ff2e97aac 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -2072,15 +2072,6 @@ void ClangExpressionDeclMap::AddOneFunction(NameSearchContext &context,
       return;
     }
   } else if (symbol) {
-    // Don't insert a generic function decl for C++ symbol names.
-    // Creating a generic function decl is almost surely going to cause troubles
-    // as it breaks Clang/Sema invariants and causes crashes in clang while
-    // we're trying to evaluate the expression.
-    // This means users can't call C++ functions by mangled name when there
-    // are no debug info (as it happens for C symbol, e.g. printf()).
-    if (CPlusPlusLanguage::IsCPPMangledName(
-            symbol->GetMangled().GetMangledName().GetCString()))
-      return;
     fun_address = symbol->GetAddress();
     function_decl = context.AddGenericFunDecl();
     is_indirect_function = symbol->IsIndirect();