summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters/ValueObjectPrinter.cpp
diff options
context:
space:
mode:
authorEnrico Granata <egranata@apple.com>2015-06-17 02:06:24 +0000
committerEnrico Granata <egranata@apple.com>2015-06-17 02:06:24 +0000
commitca201238ae8dd8875911baf6855917d801c00e2a (patch)
treea70c7ec71cb7ea8d158a56d7f9bdd09064d8b0f1 /lldb/source/DataFormatters/ValueObjectPrinter.cpp
parent8096d34e5f14cc4ba65a052376459d714b995795 (diff)
downloadbcm5719-llvm-ca201238ae8dd8875911baf6855917d801c00e2a.tar.gz
bcm5719-llvm-ca201238ae8dd8875911baf6855917d801c00e2a.zip
Fix an issue where the oneliner printing of variables would ignore custom formatting
Because vector types use their formats in special ways (i.e. children get generated based on them), this change by itself would cause a regression in printing vector types with some custom formats Work around that issue by special casing vector types out of this format-passdown mode. I believe there is a more general feature to be designed in this space, but until I see more cases of interest, I am going to leave this as a special case Fixes rdar://20810062 llvm-svn: 239873
Diffstat (limited to 'lldb/source/DataFormatters/ValueObjectPrinter.cpp')
-rw-r--r--lldb/source/DataFormatters/ValueObjectPrinter.cpp18
1 files changed, 16 insertions, 2 deletions
diff --git a/lldb/source/DataFormatters/ValueObjectPrinter.cpp b/lldb/source/DataFormatters/ValueObjectPrinter.cpp
index 7c794ee2dda..822c25b41fa 100644
--- a/lldb/source/DataFormatters/ValueObjectPrinter.cpp
+++ b/lldb/source/DataFormatters/ValueObjectPrinter.cpp
@@ -83,6 +83,7 @@ ValueObjectPrinter::Init (ValueObject* valobj,
m_value.assign("");
m_summary.assign("");
m_error.assign("");
+ m_children_format.reset();
}
bool
@@ -502,12 +503,25 @@ ValueObjectPrinter::PrintChildrenPreamble ()
}
}
+lldb::Format
+ValueObjectPrinter::GetFormatForChildElements ()
+{
+ // we special case vector types here because for a vector type the format is not trivially passed down but is one of the things
+ // the synthetic child provider uses to decide how to produce children in the first place - in general this might be something
+ // we'd want to expose in some cleaner way, but until there is more than one instance of this, it's hard to design this capability
+ // in a sensible way, so for now, leave this alone as a special case
+ if (m_children_format.hasValue())
+ return m_children_format.getValue();
+
+ return (m_children_format = m_clang_type.IsVectorType(nullptr, nullptr) ? lldb::eFormatInvalid : options.m_format).getValue();
+}
+
void
ValueObjectPrinter::PrintChild (ValueObjectSP child_sp,
uint32_t curr_ptr_depth)
{
DumpValueObjectOptions child_options(options);
- child_options.SetFormat(options.m_format).SetSummary().SetRootValueObjectName();
+ child_options.SetFormat(GetFormatForChildElements()).SetSummary().SetRootValueObjectName();
child_options.SetScopeChecked(true).SetHideName(options.m_hide_name).SetHideValue(options.m_hide_value)
.SetOmitSummaryDepth(child_options.m_omit_summary_depth > 1 ? child_options.m_omit_summary_depth - 1 : 0);
if (child_sp.get())
@@ -630,7 +644,7 @@ ValueObjectPrinter::PrintChildrenOneLiner (bool hide_names)
}
child_sp->DumpPrintableRepresentation(*m_stream,
ValueObject::eValueObjectRepresentationStyleSummary,
- lldb::eFormatInvalid,
+ GetFormatForChildElements(),
ValueObject::ePrintableRepresentationSpecialCasesDisable);
}
}
OpenPOWER on IntegriCloud