[Lldb-commits] [lldb] [lldb][[DWARFDeclContext] Add function to extract qualified names as vector (PR #77349)

[Felipe de Azevedo Piovezan via lldb-commits]

================
@@ -68,6 +68,11 @@ class DWARFDeclContext {
 
   const char *GetQualifiedName() const;
 
+  /// Returns a vector of string, one string per entry in the fully qualified
+  /// name. For example, for the DeclContext `A::B::C`, this methods returns
+  /// `{"C", "B", "A"}`
+  llvm::SmallVector<llvm::StringRef> GetQualifiedNameAsVector() const;
----------------
felipepiovezan wrote:

> No terribly good reason: DeclContext, DWARFDeclContext and CompilerDeclContext were already taken.

> I believe this was done a long time ago for the -gmodules support where we have a context to a type and we want to find it in the right module's DWARF.

Got it! Sounds like if we make a new common class we may have an opportunity to rename this. Depending on what we settle with, the most uninspired name might be the most appropriate: NameAndTag, or NameAndKind. Makes it pretty obvious what the class is.

> Let me know if this creates a burden or if you think this is the wrong approach

I agree having a common API is a good thing, but it feels orthogonal to what this patch was hoping to facilitate, as it would require putting IDX_Parent work on pause to go find a common interface for the existing plugins. 

This commit was here just to avoid having to write a couple of extra `Entry.Name.toStringRef`s in a subsequent patch, so I don't mind abandoning it until we have such a common interface.

> Setting a breakpoint by full path on a large project might show some speed differences, 

This is exactly what I tried, and it made no difference. Even made the paths extra lengthy.

> StringRef::operator==() is efficient enough to just look at the lengths first so there may be fewer string compares...

This is also exactly what I disabled. I tagged it with `attribute::noopt` (which also disables inlining) and also removed the shortcut that compares the lengths first, i.e., I made the comparator look at every character every time. Didn't make a dent on breakpoint setting performance. This makes me believe the opposite is true: if we got rid of ConstString, things may potentially be faster because of all the overhead in conjuring ConstStrings from other string representations (my experiments didn't replace ConstString, merely rewrote their comparator to be as slow as possible). But we are neck-deep in the program-lifetime ocean, so maybe some other day 😅 

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