================
@@ -965,6 +965,22 @@ SBTarget SBDebugger::GetDummyTarget() {
return sb_target;
}
+void SBDebugger::DispatchClientTelemetry(const lldb::SBStructuredData &entry) {
+ LLDB_INSTRUMENT_VA(this);
+ // Disable client-telemetry for SWIG.
+ // This prevent arbitrary python client (pretty printers, whatnot) from
sending
+ // telemetry without vendors knowing.
+#ifndef SWIG
----------------
labath wrote:
Soo, my reason for suggesting `ifndef SWIG` is because that hides the API from
python (specifically from python data formatters). While I think it *might* be
reasonable to provide data formatters a way to report their health metrics, I
don't think that's a problem you're trying to solve here. I'm also aware that
it's an imperfect solution as it makes no difference between "python code
running in lldb" and "python code driving lldb". I think the "outside vs.
inside" distinction is what we'd really want to capture here since in theory
one should be able rewrite lldb-dap in python and have everything still work,
but I don't know how to forbid one without the other.
Bottom line: I'm not insisting on the `ifndef SWIG`, I'm just trying to make
sure there's a reasonable story for who can call this API. If you can make your
use case work without that, even better.
https://github.com/llvm/llvm-project/pull/129728
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits