[llvm] [llvm]Add a simple Telemetry framework (PR #102323)

Vy Nguyen via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 11 07:17:43 PST 2024


================
@@ -111,22 +108,22 @@ struct TelemetryInfo {
 class Destination {
 public:
   virtual ~Destination() = default;
-  virtual Error emitEntry(const TelemetryInfo *Entry) = 0;
+  virtual Error receiveEntry(const TelemetryInfo *Entry) = 0;
   virtual llvm::StringLiteral name() const = 0;
 };
 
 /// This class is the main interaction point between any LLVM tool
 /// and this framework.
 /// It is responsible for collecting telemetry data from the tool being
 /// monitored and transmitting the data elsewhere.
-class Telemeter {
+class Manager {
 public:
-  // Invoked upon tool startup
-  virtual void atStartup(llvm::StringRef ToolPath, TelemetryInfo *Entry) = 0;
-
-  // Invoked upon tool exit.
-  virtual void atExit(llvm::StringRef ToolPath, TelemetryInfo *Entry) = 0;
+  // Dispatch Telemetry data to the Destination(s).
+  // The argument is non-const because the Manager may add or remove
+  // data from the entry.
----------------
oontvoo wrote:

The use-case for this is 
- #1: for the `Manager` to attache the SessionId to each entry. 
- #2: in the LLDB's implementation of Manager, we'd like to add some additional data to certain entries. (Also ideally we want to put this work inside the Manager code rather than in the client code).

Additionally, the LLDB layer already defines additional subclasses of TelemetryInfo with more fields added.
So I prefer not to have to do the wrapper design that you propose. 
If, for some reason, this non-const argument seems problematic to your use case, i believe you can define an additional `dispatch(const TelemetryInfo*)` overload in your implementation and use it exclusively, right?



https://github.com/llvm/llvm-project/pull/102323


More information about the llvm-commits mailing list