[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

[Greg Clayton via lldb-commits]

================
@@ -2225,7 +2225,8 @@ void ObjectFileMachO::ParseSymtab(Symtab &symtab) {
   const char *file_name = file.GetFilename().AsCString("<Unknown>");
   LLDB_SCOPED_TIMERF("ObjectFileMachO::ParseSymtab () module = %s", file_name);
   LLDB_LOG(log, "Parsing symbol table for {0}", file_name);
-  Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name));
+  Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name),
+                    Progress::ProgressReportType::eAggregateProgressReport);
----------------
clayborg wrote:

> @clayborg I understand your point but how would a category string be different from filtering out the progress events based on the progress title string (or parts of it) ?

It would stop clients from having to add logic to try and look for common substrings, but other than that not much different. It would allow progress titles to vary quite a bit more, but they don't right now.

> I see how certain progress reports could be relevant to linux where we wouldn't want to surface it on macOS. The reason we came up with this approach is precisely because we prefer having LLDB tell its clients what progress should be displayed, rather than having the filtering logic be done in the client.

Not sure I follow? Are you saying if `is_aggregate == true` that we are letting users know they should ignore these progress reports? And we are setting to true for all progress reports except for Swift and a few other rarely used ones?

> May we could keep a list of blacklisted progress title / categories for every platform and either submit progress reports if they're not in that list or have an SBAPI to fetch the list of blacklisted progresses from the client ? What do you think about this ?

One ideas is if we have categories, we could have settings that could control if the progress reports for a given category should be displayed. Those could easily be set after initializing a debugger object.

> (also cc @JDevlieghere since he will probably have some opinions about this).

Sounds good

The entire idea of the progress dialogs is to provide insight for when the debugger seems to be stalled, but it is actually doing work. If we have any progress items that are not useful, we should remove them. But parsing symbol tables, even on Mac, can sometimes take a few seconds on larger binaries, so I find this useful when running LLDB from the command line. Indexing DWARF is a huge time sync for really large projects which often can take many minutes to complete and when I load them on the command line, seeing the progress in the terminal is very useful.

So a few things that seem to stand out to me:
- Darwin will never see the `Manually indexing DWARF for <path>` progress dialogs, and these are needed and should always be displayed.
- Darwin does see the `Parsing symbol table for <path> progress dialogs, but many are fast and probably are part of the problem you want to fix?
- "Loading Apple DWARF index for <path>" has no real work being done here, just initializing a memory buffer, seems like it should probably be removed to cut down on the noise?
- "Loading DWARF5 index for <path>" is the same kind of thing for both Darwin and linux (no real work to be done, the accelerator tables are "ready to use")
- "Locating external symbol file for <path>" seems useful if the download can take a while

I don't see any other uses in the upstream LLDB sources.

But my main point is we make Progress dialogs for a reason and we should make sure they are useful and that everyone wants them. 


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