aprantl added a comment. Nice! I have a suggestion to speed up the test and make it a little more robust.
================ Comment at: lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp:82 Log *m_log; + std::unique_ptr<Progress> m_current_progress_up; + std::vector<std::string> m_module_build_stack; ---------------- kastiglione wrote: > mib wrote: > > `Progress` makes use of RAII to complete the progress report event. > > > > I think a local variable would be more suitable. > Since this is a callback, and the work being done doesn't happen in this > function, I reasoned that that a local wouldn't match the semantics. Since > this function is so short lived, the Progress would be immediately destructed > and completed, but the work of building the module is not yet completed. > Also, when an event is completed, the console text is cleared. As a result, > the user doesn't see which module is currently building. Might be good to comment this? ================ Comment at: lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp:198 + // End the previous event before starting a new event. + m_current_progress_up.reset(nullptr); + m_current_progress_up.reset(new Progress( ---------------- mib wrote: > I guess this could be refactored in a lambda function IIUC, this is redundant? Ah — unless this is about the ordering and having the old one destroyed first, in which case this makes sense. ================ Comment at: lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp:199 + m_current_progress_up.reset(nullptr); + m_current_progress_up.reset(new Progress( + llvm::formatv("Currently building module {0}", module_name))); ---------------- For some reason I prefer writing `m_current_progress_up = std::make_unique<Progress>(...)` but I think for all practical intents this is equivalent. ================ Comment at: lldb/test/API/functionalities/progress_reporting/clang_modules/TestClangModuleBuildProgress.py:20 + # Ensure an empty module cache. + mod_cache = os.path.join(self.getBuildDir(), "new-modules") + if os.path.isdir(mod_cache): ---------------- FYI this is the same as `mod_cache = self.getBuildArtifact("new-modules")` ================ Comment at: lldb/test/API/functionalities/progress_reporting/clang_modules/TestClangModuleBuildProgress.py:36 + # Trigger module builds. + self.expect("p @2") + ---------------- This is a really indirect way of triggering a module import. Why not `expr -- @import Foo`? This way you can also import an empty module instead of an expensive uncached compilation of all of Foundation. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D140056/new/ https://reviews.llvm.org/D140056 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits