[llvm] [llvm-debuginfo-analyzer] Add support for parsing DWARF / CodeView SourceLanguage (PR #137223)

[Javier Lopez-Gomez via llvm-commits]

================
@@ -64,6 +67,22 @@ using LVElementKindSet = std::set<LVElementKind>;
 using LVElementDispatch = std::map<LVElementKind, LVElementGetFunction>;
 using LVElementRequest = std::vector<LVElementGetFunction>;
 
+/// A source language supported by any of the debug info representations.
+struct LVSourceLanguage {
+  LVSourceLanguage() = default;
+  LVSourceLanguage(llvm::dwarf::SourceLanguage SL) : Language(SL) {}
+  LVSourceLanguage(llvm::codeview::SourceLanguage SL) : Language(SL) {}
+
+  bool isValid() const { return Language.index() != 0; }
+  template <typename T> T getAs() { return std::get<T>(Language); }
+  StringRef getName() const;
+
+private:
+  std::variant<std::monostate, llvm::dwarf::SourceLanguage,
+               llvm::codeview::SourceLanguage>
+      Language;
+};
+
----------------
jalopezg-git wrote:

That sounds promising, and a bit simpler, given the existing infrastructure.

However, in the current state of this PR, we could write a `switch` statement on the returned value of `getSourceLanguage.getAs<...>()`; this particular use case would become a bit harder to support if using strings as the underlying representation.

Initially, I thought this could be supported by exposing the `LanguageIndex` data member (suggested [below](https://github.com/llvm/llvm-project/pull/137223#discussion_r2068445423)), but this is not reliable, as it depends on the interning order.

We could still go for `StringPool` + `LanguageIndex` at the cost of having to do string comparisons somewhere else (I would prefer to avoid this).

https://github.com/llvm/llvm-project/pull/137223