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