[lldb-dap] Remove an incorrect assumption on reverse requests.

[ashgti]

Reverse requests do have a 'seq' set still from VSCode. I incorrectly interpreted https://github.com/microsoft/vscode/blob/dede7bb4b7e9c9ec69155a243bb84037a40588fe/src/vs/workbench/contrib/debug/common/abstractDebugAdapter.ts#L65 to mean they have a 'seq' of '0', however the 'seq' is set in 'internalSend' here https://github.com/microsoft/vscode/blob/dede7bb4b7e9c9ec69155a243bb84037a40588fe/src/vs/workbench/contrib/debug/common/abstractDebugAdapter.ts#L178.

Removing the check that 'seq=0' on reverse requests and updating the dap_server.py impl to also set the seq.

[llvmbot]

@llvm/pr-subscribers-lldb

Author: John Harrison (ashgti)

Changes

Reverse requests do have a 'seq' set still from VSCode. I incorrectly interpreted https://github.com/microsoft/vscode/blob/dede7bb4b7e9c9ec69155a243bb84037a40588fe/src/vs/workbench/contrib/debug/common/abstractDebugAdapter.ts#L65 to mean they have a 'seq' of '0', however the 'seq' is set in 'internalSend' here https://github.com/microsoft/vscode/blob/dede7bb4b7e9c9ec69155a243bb84037a40588fe/src/vs/workbench/contrib/debug/common/abstractDebugAdapter.ts#L178.

Removing the check that 'seq=0' on reverse requests and updating the dap_server.py impl to also set the seq.

---

Full diff: https://github.com/llvm/llvm-project/pull/136210.diff

2 Files Affected:

• (modified) lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py (-4)
• (modified) lldb/tools/lldb-dap/Protocol/ProtocolBase.cpp (-5)

diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 61d7fa94479b8..a9915ba2f6de6 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -343,25 +343,21 @@ def send_recv(self, command):
                     self.send_packet(
                         {
                             "type": "response",
-                            "seq": 0,
                             "request_seq": response_or_request["seq"],
                             "success": True,
                             "command": "runInTerminal",
                             "body": {},
                         },
-                        set_sequence=False,
                     )
                 elif response_or_request["command"] == "startDebugging":
                     self.send_packet(
                         {
                             "type": "response",
-                            "seq": 0,
                             "request_seq": response_or_request["seq"],
                             "success": True,
                             "command": "startDebugging",
                             "body": {},
                         },
-                        set_sequence=False,
                     )
                 else:
                     desc = 'unknown reverse request "%s"' % (
diff --git a/lldb/tools/lldb-dap/Protocol/ProtocolBase.cpp b/lldb/tools/lldb-dap/Protocol/ProtocolBase.cpp
index bfd68448fb483..bc4fee4aa8b8d 100644
--- a/lldb/tools/lldb-dap/Protocol/ProtocolBase.cpp
+++ b/lldb/tools/lldb-dap/Protocol/ProtocolBase.cpp
@@ -163,11 +163,6 @@ bool fromJSON(json::Value const &Params, Response &R, json::Path P) {
     return false;
   }
 
-  if (seq != 0) {
-    P.field("seq").report("expected to be '0'");
-    return false;
-  }
-
   if (R.command.empty()) {
     P.field("command").report("expected to not be ''");
     return false;

[JDevlieghere]

Yeah, according to the spec all protocol messages have a sequence number and the sequence number is 1-based:

Sequence number of the message (also known as message ID). The seq for
the first message sent by a client or debug adapter is 1, and for each
subsequent message is 1 greater than the previous message sent by that
actor. seq can be used to order requests, responses, and events, and to
associate requests with their corresponding responses. For protocol
messages of type request the sequence number can be used to cancel the
request.

The spec says "can" but the sequence number is not optional.