[Lldb-commits] [lldb] [LLDB] Add more helper functions to CompilerType class (second try). (PR #73472)

[via lldb-commits]

================
@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+                     bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();
----------------
jimingham wrote:

Note that this function returns the type of the shared pointer, whereas the synthetic child providers return values of that type.  So if anything you would implement the formatter on top of this type recognition (though that only gets you a little way there, you also have to find where the value is in the smart pointer.)

It's a little awkward that these API's speak of "smart pointer" when they really mean "the system library provided memory managing smart pointer".  But I can't think of a good name to make this explicit.

However, that brings us round to the synthetic child support for "smart pointers".  That is a feature that's not limited to the standard library's notion of a smart pointer.  It really just tells lldb how to interpret the `->` in:

(lldb) frame var foo->bar

The implementation of this feature doesn't require any knowledge of what the arrow operator for foo does (it is not even required to have one).  For instance, you could use it to have lldb log uses of the `->` operator for this type in the expression parser, or whatever.  The only requirement is that you define a synthetic child provider that emulates the -> operator, returning a ValueObject from the appropriate API in the provider.

So at some point someone could redo the STL smart pointer comprehension in lldb to use the synthetic child arrow operator emulation, that's a much broader feature that what this API is promising.

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