[lldb][Core] Remove dead codepath in Mangled

[xiaobai]

Summary

Objective-C names are stored in m_demangled, not in m_mangled. The
method in the condition will never return true.

[davide]

Presumably.

[davide]

I'm curious what happens if you end up here with something like _T. Did you check?

[xiaobai]

In D79823#2032827, @davide wrote:

I'm curious what happens if you end up here with something like _T. Did you check?

I assume you're talking about swift, which should be handled by a SwiftLanguage plugin. Can Objective-C names be mangled with the swift mangling scheme?

[jingham]

Note that there is no guarantee that ObjC names won't be mangled. They aren't on macOS because the macOS linker grew up along with objC so all the weird characters it introduces into the symbol namespace ([,],-,+, ,etc...) are allowed. Way back in the day when WebObjects ran on Windows ObjC names weren't legal, and were mangled. Just saying...

lldb/source/Core/Mangled.cpp

 // within those targets.
 lldb::LanguageType Mangled::GuessLanguage() const {
   ConstString mangled = GetMangledName();
 
   if (mangled) {
     const char *mangled_name = mangled.GetCString();
     if (CPlusPlusLanguage::IsCPPMangledName(mangled_name))
       return lldb::eLanguageTypeC_plus_plus;
-    else if (ObjCLanguage::IsPossibleObjCMethodName(mangled_name))
-      return lldb::eLanguageTypeObjC;
   } else {
     // ObjC names aren't really mangled, so they won't necessarily be in the
     // mangled name slot.
     ConstString demangled_name = GetDemangledName();
     if (demangled_name 
         && ObjCLanguage::IsPossibleObjCMethodName(demangled_name.GetCString()))
       return lldb::eLanguageTypeObjC;