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

[James Henderson via llvm-commits]

================
@@ -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.
----------------
jh7370 wrote:

This comment is making me wonder whether there are cases where the non-const nature might be an issue. I can't immediately think of any, so it's probably fine, but I thought I'd share how our internal implementation tackles this (but for different reasons). Specifically, the client-facing header provides a `DispatchableEvent` class, which is essentially the same as `TelemetryInfo`. However, within the `dispatch` method, it is wrapped in a different class to attach extra data like properties about the dispatching application. We've done this to allow us to hide a range of internal implementation details, but the same technique would allow a `const` class be wrapped in a non-const one to allow more data to be added.

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