[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