================ @@ -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