[clang] [clang-tools-extra] [clangd] Use `SymbolName` to represent Objective-C selectors (PR #82061)

[Sam McCall via cfe-commits]

================
@@ -27,19 +31,45 @@ namespace tooling {
 /// //       ^~ string 0 ~~~~~         ^~ string 1 ~~~~~
 /// \endcode
 class SymbolName {
+  llvm::SmallVector<std::string, 1> NamePieces;
+
 public:
-  explicit SymbolName(StringRef Name) {
-    // While empty symbol names are valid (Objective-C selectors can have empty
-    // name pieces), occurrences Objective-C selectors are created using an
-    // array of strings instead of just one string.
-    assert(!Name.empty() && "Invalid symbol name!");
-    this->Name.push_back(Name.str());
-  }
+  SymbolName();
+
+  /// Create a new \c SymbolName with the specified pieces.
+  explicit SymbolName(ArrayRef<StringRef> NamePieces);
+  explicit SymbolName(ArrayRef<std::string> NamePieces);
+
+  explicit SymbolName(const DeclarationName &Name);
 
-  ArrayRef<std::string> getNamePieces() const { return Name; }
+  /// Creates a \c SymbolName from the given string representation.
+  ///
+  /// For Objective-C symbol names, this splits a selector into multiple pieces
+  /// on `:`. For all other languages the name is used as the symbol name.
----------------
sam-mccall wrote:

This looks too much like guesswork. For example in an ObjC++ file (which is our default parse language for *.h), SymbolName(`operator std::string`) will be parsed as the ObjC selector `[" operator std", "", "string"].

If we want to clearly distinguish the different types of names (as clang AST does) then we should avoid implicit conversions like this where it's easy to confuse the encoded/decoded state.

If we're content to mostly use strings and heuristically interpret them as selector names at the edges, that seems OK too - but then this class could just be a "split" function or so.

(This is up to you - I don't mind much what this API looks like unless we end up depending on it)


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