summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters/FormatManager.cpp
diff options
context:
space:
mode:
authorEnrico Granata <egranata@apple.com>2013-10-04 23:14:13 +0000
committerEnrico Granata <egranata@apple.com>2013-10-04 23:14:13 +0000
commita29cb0bada725d47daa0006be1a847964b29e45e (patch)
tree05a98d9df302f53ddf17041714dc5a2c54314e0d /lldb/source/DataFormatters/FormatManager.cpp
parent1f4f5d7b84034f0b9dae78f4c67ff59bff27d96c (diff)
downloadbcm5719-llvm-a29cb0bada725d47daa0006be1a847964b29e45e.tar.gz
bcm5719-llvm-a29cb0bada725d47daa0006be1a847964b29e45e.zip
<rdar://problem/12042982>
This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff: this ValueObject does not have a summary its children have no synthetic children its children are not a non-empty base class without a summary its children do not have a summary that asks for children to show up the aggregate length of all the names of all the children is <= 50 characters you did not ask to see the types during a printout your pointer depth is 0 This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?) Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be) llvm-svn: 191996
Diffstat (limited to 'lldb/source/DataFormatters/FormatManager.cpp')
-rw-r--r--lldb/source/DataFormatters/FormatManager.cpp60
1 files changed, 60 insertions, 0 deletions
diff --git a/lldb/source/DataFormatters/FormatManager.cpp b/lldb/source/DataFormatters/FormatManager.cpp
index c4debf9c259..415ecc23dde 100644
--- a/lldb/source/DataFormatters/FormatManager.cpp
+++ b/lldb/source/DataFormatters/FormatManager.cpp
@@ -305,6 +305,66 @@ FormatManager::GetSingleItemFormat(lldb::Format vector_format)
}
}
+bool
+FormatManager::ShouldPrintAsOneLiner (ValueObject& valobj)
+{
+ // if this object has a summary, don't try to do anything special to it
+ // if the user wants one-liner, they can ask for it in summary :)
+ if (valobj.GetSummaryFormat().get() != nullptr)
+ return false;
+
+ // no children, no party
+ if (valobj.GetNumChildren() == 0)
+ return false;
+
+ size_t total_children_name_len = 0;
+
+ for (size_t idx = 0;
+ idx < valobj.GetNumChildren();
+ idx++)
+ {
+ ValueObjectSP child_sp(valobj.GetChildAtIndex(idx, true));
+ // something is wrong here - bail out
+ if (!child_sp)
+ return false;
+ // if we decided to define synthetic children for a type, we probably care enough
+ // to show them, but avoid nesting children in children
+ if (child_sp->GetSyntheticChildren().get() != nullptr)
+ return false;
+
+ total_children_name_len += child_sp->GetName().GetLength();
+
+ // 50 itself is a "randomly" chosen number - the idea is that
+ // overly long structs should not get this treatment
+ // FIXME: maybe make this a user-tweakable setting?
+ if (total_children_name_len > 50)
+ return false;
+
+ // if a summary is there..
+ if (child_sp->GetSummaryFormat())
+ {
+ // and it wants children, then bail out
+ if (child_sp->GetSummaryFormat()->DoesPrintChildren())
+ return false;
+ }
+
+ // if there is a base-class...
+ if (child_sp->IsBaseClass())
+ {
+ // and it has children..
+ if (child_sp->GetNumChildren())
+ {
+ // ...and no summary...
+ // (if it had a summary and the summary wanted children, we would have bailed out anyway
+ // so this only makes us bail out if this has no summary and we would then print children)
+ if (!child_sp->GetSummaryFormat())
+ return false; // then bail out
+ }
+ }
+ }
+ return true;
+}
+
ConstString
FormatManager::GetValidTypeName (const ConstString& type)
{
OpenPOWER on IntegriCloud