================
@@ -56,13 +60,83 @@ struct LLDBBaseTelemetryInfo : public
llvm::telemetry::TelemetryInfo {
void serialize(llvm::telemetry::Serializer &serializer) const override;
};
+/// Describes the exit status of a debugger.
+struct ExitDescription {
+ int exit_code;
+ std::string description;
+};
+
+struct DebuggerTelemetryInfo : public LLDBBaseTelemetryInfo {
----------------
labath wrote:
I have many thoughts here. In no particular order, they are:
- I don't find the I/O argument particularly convincing, as I expect that any
reasonable backend will want to cache/batch sending of these entries anyway
- I can believe that for analysis purposes, it's nicer to have a single "this
is everything I know about the environment of the session" entry. I can also
understand the desire for easy filtering of unwanted data. I don't know if
there's a reasonable compromise here. Group this data into two sub-structs?
- the collect-then-filter approach makes sense for things which cannot be
collected in any other way. However, pretty much everything being collected
here is static data. There's no reason why it has to be collected at a
particular location. (Like, even if we just stopped collecting the username
here, a backend could just refetch it if it wanted to). Maybe we could not
include things that recomputed in the backend? Or at least things that are
likely to be problematic?
https://github.com/llvm/llvm-project/pull/127696
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
