================
@@ -615,7 +615,16 @@ bool ValueObject::GetSummaryAsCString(TypeSummaryImpl
*summary_ptr,
m_synthetic_value->UpdateValueIfNeeded(); // the summary might depend on
// the synthetic children being
// up-to-date (e.g. ${svar%#})
- summary_ptr->FormatObject(this, destination, actual_options);
+ SummaryStatistics &summary_stats = GetExecutionContextRef()
+ .GetProcessSP()
+ ->GetTarget()
+
.GetSummaryStatisticsForProvider(GetTypeName());
+ /// Construct RAII types to time and collect data on summary creation.
+ SummaryStatistics::SummaryInvocation summary_inv(summary_stats);
----------------
Jlalond wrote:
This is actually the biggest reason I pushed these changes 'as is', because I
wanted feedback on this. The goal here was to make the increment of timing as
simple as possible.
Elapsed time handles it's scope by it's lifetime, and I wanted to mirror that.
In the future we may want to add more side-effects and data collection when a
summary-call is complete. Such as giving the user a warning if a formatter was
so many multiples off the average.
Where I'm not sure is if we should make this one RAII object with an elapsed
object internal to it's lifetime so you get all the scoping side effects rolled
up into one
https://github.com/llvm/llvm-project/pull/102708
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
