[Lldb-commits] [lldb] [lldb][progress][NFC] Add groundwork to keep track of progress reports (PR #81026)

[Greg Clayton via lldb-commits]

================
@@ -99,6 +105,10 @@ class Progress {
 private:
   void ReportProgress();
   static std::atomic<uint64_t> g_id;
+  static std::atomic<uint64_t> g_refcount;
+  /// Map that tracks each progress object and if we've seen its start and stop
+  /// events
+  static std::unordered_map<std::string, uint64_t> g_map;
----------------
clayborg wrote:

> We spoke about this a little offline but at the moment although Progress reports hold on to debugger instances, these instances are null by default and most Progress reports don't give a debugger instance in their instantiation so we wouldn't be able to have a debugger instance hold on to their own map of ongoing progress reports.
> 
> @clayborg Having a progress report holding on to a debugger instance is a good idea, but if we want to use a map to keep track of ongoing reports we need to know what will own the map? Do we want the map to be owned by a debugger instance or could the progress class hold on to its own map of ongoing reports? In the case of the former we would then want to enforce that progress reports have valid debugger instances and in the latter we could remove the `debugger` field from the reports altogether.

The main question is if we want all progress reports to follow the currently selected mode (coalesce or individual) or if we want them to be able to pick which one they are. I would vote to have a global setting that controls if we deliver things, but would love to hear what others think.

Each Progress instance _can_ have a debugger, but most don't, and those will get delivered to all debugger instances. So I would say that this map should live in each debugger object because `Progress` objects _can_ have a debugger set, and if they do, they will only get delivered to _that_ debugger. 

So my suggestion here is to:
- not change anything in Progress.h/cpp
- move the progress categorization code into each debugger object
- in `PrivateReportProgress` we check if anyone is listening to the new `eBroadcastBitProgressByCategory` bit, and then and _only_ then do we do any of the category counting.

So the code in `PrivateReportProgress` will now look something like:
```
static void PrivateReportProgress(Debugger &debugger, uint64_t progress_id,
                                  std::string title, std::string details,
                                  uint64_t completed, uint64_t total,
                                  bool is_debugger_specific) {
  // Only deliver progress events if we have any progress listeners.
  if (debugger.GetBroadcaster().EventTypeHasListeners(Debugger::eBroadcastBitProgressByCategory))
    PrivateReportProgressByCategory(debugger, progress_id, is_debugger_specific, completed, total, is_debugger_specific);
  const uint32_t event_type = Debugger::eBroadcastBitProgress;
  if (!debugger.GetBroadcaster().EventTypeHasListeners(event_type))
    return;
  EventSP event_sp(new Event(
      event_type,
      new ProgressEventData(progress_id, std::move(title), std::move(details),
                            completed, total, is_debugger_specific)));
  debugger.GetBroadcaster().BroadcastEvent(event_sp);
}
```
Then we write a new `PrivateReportProgressByCategory()` function that will do all this book keeping and coordingate with the debugger which will own the category ref count map

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