================
@@ -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:
> Adding a string to represent the category (one of a possible vector of
> strings for each operation even?) looks like a good idea though.
Seems to me that a `category` string that could be anything ("Parsing symbol
tables" or "Indexing DWARF" or "Parsing DWARF") would allow us to group similar
notifications together in an IDE better than a single
`ProgressReportType::eAggregateProgressReport` vs
`ProgressReportType::eNonAggregateProgressReport` enum value. With this
solution, does this mean that all notifications that with `is_aggregate ==
true` would show up in one area and `is_aggregate == false` would show up
another area? If we use a `category` string, any concurrent notifications that
share the same `category` could show up under some UI that displayed the
`category` string and allowed it to be expanded
https://github.com/llvm/llvm-project/pull/69516
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
