[Lldb-commits] [lldb] [lldb][lldb-dap] use the new protocol for setVariable requests. (PR #137803)

[Ebuka Ezike via lldb-commits]

================
@@ -294,6 +294,75 @@ bool fromJSON(const llvm::json::Value &, LaunchRequestArguments &,
 /// field is required.
 using LaunchResponseBody = VoidResponse;
 
+/// Arguments for `setVariable` request.
+struct SetVariableArguments {
+  /// The reference of the variable container. The `variablesReference` must
+  /// have been obtained in the current suspended state. See 'Lifetime of Object
+  ///  References' in the Overview section for details.
+  uint64_t variablesReference;
+
+  /// The name of the variable in the container.
+  std::string name;
+
+  /// The value of the variable.
+  std::string value;
+
+  /// Specifies details on how to format the response value.
+  ValueFormat format;
+};
+bool fromJSON(const llvm::json::Value &, SetVariableArguments &,
+              llvm::json::Path);
+
+/// Response to `setVariable` request.
+struct SetVariableResponseBody {
+
+  /// The new value of the variable.
+  std::string value;
+
+  /// The type of the new value. Typically shown in the UI when hovering over
+  /// the value.
+  std::optional<std::string> type;
+
+  /// If `variablesReference` is > 0, the new value is structured and its
+  /// children can be retrieved by passing `variablesReference` to the
+  /// `variables` request as long as execution remains suspended. See 'Lifetime
+  /// of Object References' in the Overview section for details.
+  ///
+  /// If this property is included in the response, any `variablesReference`
+  /// previously associated with the updated variable, and those of its
+  /// children, are no longer valid.
+  std::optional<uint64_t> variablesReference;
+
+  /// The number of named child variables.
+  /// The client can use this information to present the variables in a paged
+  /// UI and fetch them in chunks.
+  /// The value should be less than or equal to 2147483647 (2^31-1).
+  std::optional<uint64_t> namedVariables;
----------------
da-viper wrote:

I think we can used the default uint64_t for everything except the ones that have a constraint such as this one. 

ie uint64_t for numbers, int32_t for integers., and if constrained use what it wants.  

what do you think?  

> The content part is encoded using utf-8.
> integers defined in the protocol (JSON schema type integer) may be represented as 32 bit signed integers, 
> although` some properties disallow negative values. numbers in the protocol (JSON schema type number) may 
> be represented as 64 bit floating point numbers.

>From https://microsoft.github.io/debug-adapter-protocol/overview



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