[Lldb-commits] [lldb] [lldb] Update dwim-print to show expanded objc instances (PR #117500)

Dave Lee via lldb-commits lldb-commits at lists.llvm.org
Wed Nov 27 18:13:27 PST 2024


================
@@ -87,7 +87,8 @@ void CommandObjectDWIMPrint::DoExecute(StringRef command,
 
   DumpValueObjectOptions dump_options = m_varobj_options.GetAsDumpOptions(
       m_expr_options.m_verbosity, m_format_options.GetFormat());
-  dump_options.SetHideRootName(suppress_result);
+  dump_options.SetHideRootName(suppress_result)
+      .SetExpandPointerTypeFlags(lldb::eTypeIsObjC);
----------------
kastiglione wrote:

Here's my thinking: most of the time, I want top level pointers to be expanded (as c++ references are). But each of the C based language has its considerations.

For ObjC, I think all top level objects should be expanded, and I can't think of any counter arguments.

For C++, I also want top level pointers to be expanded – however raw pointers are less common. In C++ I would like to see top level smart pointers be expanded.

For C, I am less sure what, if anything, to do about top level pointers. First, I don't write a lot of C and have less experience to form opinions. Second, in C a pointer might be just as likely to be a buffer/array, and expanding a buffer as a single pointer would be misleading.

Coming back to your question: I would like to see C++ raw pointers expanded, and hopefully smart pointers too. I would leave C pointers alone. I guess I need to raise this on the forums, and find some buy in. As part of that, we can determine should pointer expansion be specific to `dwim-print`, or should some/all of it apply to `frame var`/`expr` too.

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


More information about the lldb-commits mailing list