Fix type category matching to source language.

[vadimcn]

Summary

Use exact equality for category language matching, for all languages, except those specifically mentioned.

[vadimcn]

Though... wouldn't "category_lang == valobj_lang" be a sane default behavior for any languages not mentioned specifically below?

[granata.enrico]

On the surface, that looks correct to me. However I don't work on LLDB anymore and have been out of the loop enough that I don't feel comfortable approving this change. I believe Jim Ingham is Data Formatter Overlord these days.

[jingham]

It does make sense to me that any category language that has a name should by default to be an exact match for the valobj language. If we're going to choose that as a rule, then we should eliminate all the explicitly listed languages that just require an exact match. That will make the code clearer.

It looks like Go has been using the default "all valobj's match" rule. I don't know it that was intentional or not, if somebody who uses Go knows, they should chime in.

[vadimcn]

Rust and Go are not the only missing languages. Looks like all of the newly-added DWARF5 language codes are not covered here.

[jingham]

Yes, the only reason I mentioned Go is that there is actually an lldb Language plugin for Go, but not for any of the other languages, so there's a little more support there to potentially break.

source/DataFormatters/TypeCategory.cpp

#endif
       m_change_listener(clist), m_mutex(), m_name(name), m_languages() {
   for (const lldb::LanguageType lang : langs)
     AddLanguage(lang);
 }
 
 static bool IsApplicable(lldb::LanguageType category_lang,
                          lldb::LanguageType valobj_lang) {
   switch (category_lang) {
-  // these are not languages that LLDB would ordinarily deal with
-  // only allow an exact equality here, since we really don't know
-  // any better
-  case eLanguageTypeAda83:
-  case eLanguageTypeCobol74:
-  case eLanguageTypeCobol85:
-  case eLanguageTypeFortran77:
-  case eLanguageTypeFortran90:
-  case eLanguageTypePascal83:
-  case eLanguageTypeModula2:
-  case eLanguageTypeJava:
-  case eLanguageTypeAda95:
-  case eLanguageTypeFortran95:
-  case eLanguageTypePLI:
-  case eLanguageTypeUPC:
-  case eLanguageTypeD:
-  case eLanguageTypePython:
+  // Unless we know better, allow only exact equality.
+  default:
     return category_lang == valobj_lang;
 
   // the C family, we consider it as one
   case eLanguageTypeC89:
   case eLanguageTypeC:
   case eLanguageTypeC99:
     return valobj_lang == eLanguageTypeC89 || valobj_lang == eLanguageTypeC ||
            valobj_lang == eLanguageTypeC99;
static bool IsApplicable(lldb::LanguageType category_lang,
 
   // ObjC++ knows about C,C++,ObjC and ObjC++
   case eLanguageTypeObjC_plus_plus:
     return valobj_lang == eLanguageTypeC89 || valobj_lang == eLanguageTypeC ||
            valobj_lang == eLanguageTypeC99 ||
            valobj_lang == eLanguageTypeC_plus_plus ||
            valobj_lang == eLanguageTypeObjC;
 
-  default:
+  // Categories with unspecified language match everything.
   case eLanguageTypeUnknown:
     return true;
   }
 }
 
 bool TypeCategoryImpl::IsApplicable(ValueObject &valobj) {
   lldb::LanguageType valobj_lang = valobj.GetObjectRuntimeLanguage();
   for (size_t idx = 0; idx < GetNumLanguages(); idx++) {