================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
