[lldb] Fix libstdc++ 11's std::unique_ptr affecting LLDB testsuite TestDataFormatterStdUniquePtr.py

[jankratochvil]

Summary

This is a part of D101237 to fix LLDB testsuite with GCC 11 installed (and its libstdc++). Any non-trivial handling of std::unique_ptr still asserts LLDB, that is the rest of D101237.

[teemperor]

I think the way the provider is supposed to work is that there is always deleter child as long as it's not default_delete<T>, so I think we have to check for the name to avoid that we also hide an empty user-specified deleter.

ValueObjectSP del_obj = tuple_frontend->GetChildAtIndex(1);
if (del_obj) {
  ConstString del_name = del_obj->GetDisplayTypeName();
  if (!del_name.GetStringRef().startswith("std::default_delete<"))
    m_del_obj = del_obj->Clone(ConstString("deleter")).get();
}

(Technically that would hide the deleter if the user specifies a default-deleter that just happens to be compatible, but that seems like an obscure corner case so this seems "good enough").

[jankratochvil]

So I think you can check-in your patch. I would just copy-paste it.

[jankratochvil]

In D104283#2818693, @teemperor wrote:

(Technically that would hide the deleter if the user specifies a default-deleter that just happens to be compatible, but that seems like an obscure corner case so this seems "good enough").

Personally I think if there is the pointer (and sizeof(std::unique_ptr<XXX, YYY> == 16) there should be the "deleter =" specified even if it is default deleter. So I rather disagree with your patch. But whetever, it would be nice to finally fix it for the last stable Fedora release.

[teemperor]

Personally I think if there is the pointer (and sizeof(std::unique_ptr<XXX, YYY> == 16) there should be the "deleter =" specified even if it is default deleter.

I don't think that it can happen that sizeof(ptr) == 16 with a reasonable unique_ptr/default_delete implementation, but I think in theory it could be possible.

But anyway, after some offline discussion with @jankratochvil the consensus was:

• We should hide the deleter if it's stateless (default_delete or a user-specified deleter that is empty) as the less verbose output is more useful for command line users.
• Users that care about the (user-specified) empty deleter (or the default deleter) can always inspect the type via the template argument. That anyway has to happen via the SB API and the ValueObject doesn't provide a great benefit there.

So this patch LGTM, but please update the update comment when landing to something like:

// Add a 'deleter' child if there was a non-empty deleter type specified.
// 
// The object might have size=1 in the TypeSystem but occupies no dedicated storage due
// to no_unique_address, so infer the actual size from the total size of the unique_ptr class.
// If sizeof(unique_ptr) == sizeof(void*) then the deleter is empty and should be hidden.

[jankratochvil]

In D104283#2818897, @teemperor wrote:

• We should hide the deleter if it's stateless (default_delete or a user-specified deleter that is empty) as the less verbose output is more useful for command line users.

My point of view is to rather more closely show what is physically stored in the unique_ptr.

lldb/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp

bool LibStdcppUniquePtrSyntheticFrontEnd::Update() {
 
   std::unique_ptr<SyntheticChildrenFrontEnd> tuple_frontend(
       LibStdcppTupleSyntheticFrontEndCreator(nullptr, tuple_sp));
 
   ValueObjectSP ptr_obj = tuple_frontend->GetChildAtIndex(0);
   if (ptr_obj)
     m_ptr_obj = ptr_obj->Clone(ConstString("pointer")).get();
 
+  // Add a 'deleter' child if there was a non-empty deleter type specified.
+  //
+  // The object might have size=1 in the TypeSystem but occupies no dedicated
+  // storage due to no_unique_address, so infer the actual size from the total
+  // size of the unique_ptr class. If sizeof(unique_ptr) == sizeof(void*) then
+  // the deleter is empty and should be hidden.
+  if (tuple_sp->GetByteSize() > ptr_obj->GetByteSize()) {
     ValueObjectSP del_obj = tuple_frontend->GetChildAtIndex(1);
     if (del_obj)
       m_del_obj = del_obj->Clone(ConstString("deleter")).get();
+  }
 
   if (m_ptr_obj) {
     Status error;
     ValueObjectSP obj_obj = m_ptr_obj->Dereference(error);
     if (error.Success()) {
       m_obj_obj = obj_obj->Clone(ConstString("object")).get();
     }
   }