[Lldb-commits] [lldb] [lldb][progress] Add progress manager class (PR #81319)

[Jonas Devlieghere via lldb-commits]

================
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
                              m_debugger_id);
   }
 }
+
+void ProgressManager::Initialize() {
+  lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+  InstanceImpl().emplace();
+}
+
+void ProgressManager::Terminate() {
+  lldbassert(InstanceImpl() &&
+             "A progress report manager has already been terminated.");
+  InstanceImpl().reset();
+}
+
+std::optional<ProgressManager> &ProgressManager::InstanceImpl() {
+  static std::optional<ProgressManager> g_progress_manager;
+  return g_progress_manager;
+}
+
+ProgressManager::ProgressManager() : m_progress_map() {}
+
+ProgressManager::~ProgressManager() {}
+
+ProgressManager &ProgressManager::Instance() { return *InstanceImpl(); }
----------------
JDevlieghere wrote:

Yeah, I understand why we might want to leak the vector and do in other places. But do you think we should just do that unconditionally, no matter whether it's a problem or not? The other subsystems I mention use the same approach and they don't crash in production even though they don't check the optional before dereferencing it (treating it as a precondition). 

I guess the point I'm trying to make is let's not leak it proactively, but use the stricter approach to force a crash/assert in debug builds and tests, and try to avoid these issues, rather than work around them. If we find that it does end up crashing because someone emits a progress report when we're shutting down LLDB **and** we've investigated the bug and think the functionality is important, I'm totally on board with leaking it. Does that sound like a reasonable compromise? 

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