JDevlieghere wrote: > Just to throw my opinion into the debate; I view Progress.h in the same way > as I view any printing to the terminal (or stdout). We already allow Python > commands, and I believe formatters, to print to the user's console. So > restricting progress because we don't want a python script to be masquerading > as LLDB seems less of a concern for me for SBProgress.
I would agree with you if the progress events were always show in the debugger console, but except for the command-line lldb, all IDEs I know of that support LLDB's progress events show it in a part of the UI that's usually not tied to debugger but displays other progress events like indexing, building, etc. I have a similar concern for logging. When people log to the console or to file, I don't really care that a command or extension is logging arbitrary data. But when you're logging to the system log (which on Darwin becomes part of a sysdiagnose, which in turn has\ pretty strict privacy requirements) those arbitrary logs become a problem. A potential solution for my concerns could be a flag that's set when logs or progress reports are created from the SB API, and LLDB can potentially handle them differently. Concretely for progress progress events, that could mean that we have a different broadcast bit that allows IDEs to subscribe to events that include or exclude those events. https://github.com/llvm/llvm-project/pull/119052 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
