Jlalond 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 then 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.
Huh, cool to learn. I agree with you then. I think we can keep it even 'simpler' than having a bit and just differentiating between 'user-space' progress and 'lldb/system-space' progress? Maybe something as simple as an enum and an overload to the API? 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
