-
Notifications
You must be signed in to change notification settings - Fork 22
/
schematypes.go
1917 lines (1581 loc) · 84.6 KB
/
schematypes.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
// Copyright 2020 Google LLC
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// https://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
// Code generated by "cmd/gentypes/gentypes.go"; DO NOT EDIT.
// DAP spec: https://microsoft.github.io/debug-adapter-protocol/specification
// See cmd/gentypes/README.md for additional details.
package dap
import "encoding/json"
// Message is an interface that all DAP message types implement with pointer
// receivers. It's not part of the protocol but is used to enforce static
// typing in Go code and provide some common accessors.
//
// Note: the DAP type "Message" (which is used in the body of ErrorResponse)
// is renamed to ErrorMessage to avoid collision with this interface.
type Message interface {
GetSeq() int
}
// RequestMessage is an interface implemented by all Request-types.
type RequestMessage interface {
Message
// GetRequest provides access to the embedded Request.
GetRequest() *Request
}
// ResponseMessage is an interface implemented by all Response-types.
type ResponseMessage interface {
Message
// GetResponse provides access to the embedded Response.
GetResponse() *Response
}
// EventMessage is an interface implemented by all Event-types.
type EventMessage interface {
Message
// GetEvent provides access to the embedded Event.
GetEvent() *Event
}
// LaunchAttachRequest is an interface implemented by
// LaunchRequest and AttachRequest as they contain shared
// implementation specific arguments that are not part of
// the specification.
type LaunchAttachRequest interface {
RequestMessage
// GetArguments provides access to the Arguments map.
GetArguments() json.RawMessage
}
// ProtocolMessage: Base class of requests, responses, and events.
type ProtocolMessage struct {
Seq int `json:"seq"`
Type string `json:"type"`
}
func (m *ProtocolMessage) GetSeq() int { return m.Seq }
// Request: A client or debug adapter initiated request.
type Request struct {
ProtocolMessage
Command string `json:"command"`
}
func (r *Request) GetRequest() *Request { return r }
// Event: A debug adapter initiated event.
type Event struct {
ProtocolMessage
Event string `json:"event"`
}
func (e *Event) GetEvent() *Event { return e }
// Response: Response for a request.
type Response struct {
ProtocolMessage
RequestSeq int `json:"request_seq"`
Success bool `json:"success"`
Command string `json:"command"`
Message string `json:"message,omitempty"`
}
func (r *Response) GetResponse() *Response { return r }
// ErrorResponse: On error (whenever `success` is false), the body can provide more details.
type ErrorResponse struct {
Response
Body ErrorResponseBody `json:"body"`
}
type ErrorResponseBody struct {
Error *ErrorMessage `json:"error,omitempty"`
}
// CancelRequest: The `cancel` request is used by the client in two situations:
// - to indicate that it is no longer interested in the result produced by a specific request issued earlier
// - to cancel a progress sequence. Clients should only call this request if the corresponding capability `supportsCancelRequest` is true.
// This request has a hint characteristic: a debug adapter can only be expected to make a 'best effort' in honoring this request but there are no guarantees.
// The `cancel` request may return an error if it could not cancel an operation but a client should refrain from presenting this error to end users.
// The request that got cancelled still needs to send a response back. This can either be a normal result (`success` attribute true) or an error response (`success` attribute false and the `message` set to `cancelled`).
// Returning partial results from a cancelled request is possible but please note that a client has no generic way for detecting that a response is partial or not.
// The progress that got cancelled still needs to send a `progressEnd` event back.
//
// A client should not assume that progress just got cancelled after sending the `cancel` request.
type CancelRequest struct {
Request
Arguments *CancelArguments `json:"arguments,omitempty"`
}
// CancelArguments: Arguments for `cancel` request.
type CancelArguments struct {
RequestId int `json:"requestId,omitempty"`
ProgressId string `json:"progressId,omitempty"`
}
// CancelResponse: Response to `cancel` request. This is just an acknowledgement, so no body field is required.
type CancelResponse struct {
Response
}
// InitializedEvent: This event indicates that the debug adapter is ready to accept configuration requests (e.g. `setBreakpoints`, `setExceptionBreakpoints`).
// A debug adapter is expected to send this event when it is ready to accept configuration requests (but not before the `initialize` request has finished).
// The sequence of events/requests is as follows:
// - adapters sends `initialized` event (after the `initialize` request has returned)
// - client sends zero or more `setBreakpoints` requests
// - client sends one `setFunctionBreakpoints` request (if corresponding capability `supportsFunctionBreakpoints` is true)
// - client sends a `setExceptionBreakpoints` request if one or more `exceptionBreakpointFilters` have been defined (or if `supportsConfigurationDoneRequest` is not true)
// - client sends other future configuration requests
// - client sends one `configurationDone` request to indicate the end of the configuration.
type InitializedEvent struct {
Event
}
// StoppedEvent: The event indicates that the execution of the debuggee has stopped due to some condition.
// This can be caused by a breakpoint previously set, a stepping request has completed, by executing a debugger statement etc.
type StoppedEvent struct {
Event
Body StoppedEventBody `json:"body"`
}
type StoppedEventBody struct {
Reason string `json:"reason"`
Description string `json:"description,omitempty"`
ThreadId int `json:"threadId,omitempty"`
PreserveFocusHint bool `json:"preserveFocusHint,omitempty"`
Text string `json:"text,omitempty"`
AllThreadsStopped bool `json:"allThreadsStopped,omitempty"`
HitBreakpointIds []int `json:"hitBreakpointIds,omitempty"`
}
// ContinuedEvent: The event indicates that the execution of the debuggee has continued.
// Please note: a debug adapter is not expected to send this event in response to a request that implies that execution continues, e.g. `launch` or `continue`.
// It is only necessary to send a `continued` event if there was no previous request that implied this.
type ContinuedEvent struct {
Event
Body ContinuedEventBody `json:"body"`
}
type ContinuedEventBody struct {
ThreadId int `json:"threadId"`
AllThreadsContinued bool `json:"allThreadsContinued,omitempty"`
}
// ExitedEvent: The event indicates that the debuggee has exited and returns its exit code.
type ExitedEvent struct {
Event
Body ExitedEventBody `json:"body"`
}
type ExitedEventBody struct {
ExitCode int `json:"exitCode"`
}
// TerminatedEvent: The event indicates that debugging of the debuggee has terminated. This does **not** mean that the debuggee itself has exited.
type TerminatedEvent struct {
Event
Body TerminatedEventBody `json:"body,omitempty"`
}
type TerminatedEventBody struct {
Restart json.RawMessage `json:"restart,omitempty"`
}
// ThreadEvent: The event indicates that a thread has started or exited.
type ThreadEvent struct {
Event
Body ThreadEventBody `json:"body"`
}
type ThreadEventBody struct {
Reason string `json:"reason"`
ThreadId int `json:"threadId"`
}
// OutputEvent: The event indicates that the target has produced some output.
type OutputEvent struct {
Event
Body OutputEventBody `json:"body"`
}
type OutputEventBody struct {
Category string `json:"category,omitempty"`
Output string `json:"output"`
Group string `json:"group,omitempty"`
VariablesReference int `json:"variablesReference,omitempty"`
Source *Source `json:"source,omitempty"`
Line int `json:"line,omitempty"`
Column int `json:"column,omitempty"`
Data json.RawMessage `json:"data,omitempty"`
}
// BreakpointEvent: The event indicates that some information about a breakpoint has changed.
type BreakpointEvent struct {
Event
Body BreakpointEventBody `json:"body"`
}
type BreakpointEventBody struct {
Reason string `json:"reason"`
Breakpoint Breakpoint `json:"breakpoint"`
}
// ModuleEvent: The event indicates that some information about a module has changed.
type ModuleEvent struct {
Event
Body ModuleEventBody `json:"body"`
}
type ModuleEventBody struct {
Reason string `json:"reason"`
Module Module `json:"module"`
}
// LoadedSourceEvent: The event indicates that some source has been added, changed, or removed from the set of all loaded sources.
type LoadedSourceEvent struct {
Event
Body LoadedSourceEventBody `json:"body"`
}
type LoadedSourceEventBody struct {
Reason string `json:"reason"`
Source Source `json:"source"`
}
// ProcessEvent: The event indicates that the debugger has begun debugging a new process. Either one that it has launched, or one that it has attached to.
type ProcessEvent struct {
Event
Body ProcessEventBody `json:"body"`
}
type ProcessEventBody struct {
Name string `json:"name"`
SystemProcessId int `json:"systemProcessId,omitempty"`
IsLocalProcess bool `json:"isLocalProcess,omitempty"`
StartMethod string `json:"startMethod,omitempty"`
PointerSize int `json:"pointerSize,omitempty"`
}
// CapabilitiesEvent: The event indicates that one or more capabilities have changed.
// Since the capabilities are dependent on the client and its UI, it might not be possible to change that at random times (or too late).
// Consequently this event has a hint characteristic: a client can only be expected to make a 'best effort' in honoring individual capabilities but there are no guarantees.
// Only changed capabilities need to be included, all other capabilities keep their values.
type CapabilitiesEvent struct {
Event
Body CapabilitiesEventBody `json:"body"`
}
type CapabilitiesEventBody struct {
Capabilities Capabilities `json:"capabilities"`
}
// ProgressStartEvent: The event signals that a long running operation is about to start and provides additional information for the client to set up a corresponding progress and cancellation UI.
// The client is free to delay the showing of the UI in order to reduce flicker.
// This event should only be sent if the corresponding capability `supportsProgressReporting` is true.
type ProgressStartEvent struct {
Event
Body ProgressStartEventBody `json:"body"`
}
type ProgressStartEventBody struct {
ProgressId string `json:"progressId"`
Title string `json:"title"`
RequestId int `json:"requestId,omitempty"`
Cancellable bool `json:"cancellable,omitempty"`
Message string `json:"message,omitempty"`
Percentage int `json:"percentage,omitempty"`
}
// ProgressUpdateEvent: The event signals that the progress reporting needs to be updated with a new message and/or percentage.
// The client does not have to update the UI immediately, but the clients needs to keep track of the message and/or percentage values.
// This event should only be sent if the corresponding capability `supportsProgressReporting` is true.
type ProgressUpdateEvent struct {
Event
Body ProgressUpdateEventBody `json:"body"`
}
type ProgressUpdateEventBody struct {
ProgressId string `json:"progressId"`
Message string `json:"message,omitempty"`
Percentage int `json:"percentage,omitempty"`
}
// ProgressEndEvent: The event signals the end of the progress reporting with a final message.
// This event should only be sent if the corresponding capability `supportsProgressReporting` is true.
type ProgressEndEvent struct {
Event
Body ProgressEndEventBody `json:"body"`
}
type ProgressEndEventBody struct {
ProgressId string `json:"progressId"`
Message string `json:"message,omitempty"`
}
// InvalidatedEvent: This event signals that some state in the debug adapter has changed and requires that the client needs to re-render the data snapshot previously requested.
// Debug adapters do not have to emit this event for runtime changes like stopped or thread events because in that case the client refetches the new state anyway. But the event can be used for example to refresh the UI after rendering formatting has changed in the debug adapter.
// This event should only be sent if the corresponding capability `supportsInvalidatedEvent` is true.
type InvalidatedEvent struct {
Event
Body InvalidatedEventBody `json:"body"`
}
type InvalidatedEventBody struct {
Areas []InvalidatedAreas `json:"areas,omitempty"`
ThreadId int `json:"threadId,omitempty"`
StackFrameId int `json:"stackFrameId,omitempty"`
}
// MemoryEvent: This event indicates that some memory range has been updated. It should only be sent if the corresponding capability `supportsMemoryEvent` is true.
// Clients typically react to the event by re-issuing a `readMemory` request if they show the memory identified by the `memoryReference` and if the updated memory range overlaps the displayed range. Clients should not make assumptions how individual memory references relate to each other, so they should not assume that they are part of a single continuous address range and might overlap.
// Debug adapters can use this event to indicate that the contents of a memory range has changed due to some other request like `setVariable` or `setExpression`. Debug adapters are not expected to emit this event for each and every memory change of a running program, because that information is typically not available from debuggers and it would flood clients with too many events.
type MemoryEvent struct {
Event
Body MemoryEventBody `json:"body"`
}
type MemoryEventBody struct {
MemoryReference string `json:"memoryReference"`
Offset int `json:"offset"`
Count int `json:"count"`
}
// RunInTerminalRequest: This request is sent from the debug adapter to the client to run a command in a terminal.
// This is typically used to launch the debuggee in a terminal provided by the client.
// This request should only be called if the corresponding client capability `supportsRunInTerminalRequest` is true.
// Client implementations of `runInTerminal` are free to run the command however they choose including issuing the command to a command line interpreter (aka 'shell'). Argument strings passed to the `runInTerminal` request must arrive verbatim in the command to be run. As a consequence, clients which use a shell are responsible for escaping any special shell characters in the argument strings to prevent them from being interpreted (and modified) by the shell.
// Some users may wish to take advantage of shell processing in the argument strings. For clients which implement `runInTerminal` using an intermediary shell, the `argsCanBeInterpretedByShell` property can be set to true. In this case the client is requested not to escape any special shell characters in the argument strings.
type RunInTerminalRequest struct {
Request
Arguments RunInTerminalRequestArguments `json:"arguments"`
}
// RunInTerminalRequestArguments: Arguments for `runInTerminal` request.
type RunInTerminalRequestArguments struct {
Kind string `json:"kind,omitempty"`
Title string `json:"title,omitempty"`
Cwd string `json:"cwd"`
Args []string `json:"args"`
Env map[string]any `json:"env,omitempty"`
ArgsCanBeInterpretedByShell bool `json:"argsCanBeInterpretedByShell,omitempty"`
}
// RunInTerminalResponse: Response to `runInTerminal` request.
type RunInTerminalResponse struct {
Response
Body RunInTerminalResponseBody `json:"body"`
}
type RunInTerminalResponseBody struct {
ProcessId int `json:"processId,omitempty"`
ShellProcessId int `json:"shellProcessId,omitempty"`
}
// StartDebuggingRequest: This request is sent from the debug adapter to the client to start a new debug session of the same type as the caller.
// This request should only be sent if the corresponding client capability `supportsStartDebuggingRequest` is true.
// A client implementation of `startDebugging` should start a new debug session (of the same type as the caller) in the same way that the caller's session was started. If the client supports hierarchical debug sessions, the newly created session can be treated as a child of the caller session.
type StartDebuggingRequest struct {
Request
Arguments StartDebuggingRequestArguments `json:"arguments"`
}
// StartDebuggingRequestArguments: Arguments for `startDebugging` request.
type StartDebuggingRequestArguments struct {
Configuration map[string]any `json:"configuration"`
Request string `json:"request"`
}
// StartDebuggingResponse: Response to `startDebugging` request. This is just an acknowledgement, so no body field is required.
type StartDebuggingResponse struct {
Response
}
// InitializeRequest: The `initialize` request is sent as the first request from the client to the debug adapter in order to configure it with client capabilities and to retrieve capabilities from the debug adapter.
// Until the debug adapter has responded with an `initialize` response, the client must not send any additional requests or events to the debug adapter.
// In addition the debug adapter is not allowed to send any requests or events to the client until it has responded with an `initialize` response.
// The `initialize` request may only be sent once.
type InitializeRequest struct {
Request
Arguments InitializeRequestArguments `json:"arguments"`
}
// InitializeRequestArguments: Arguments for `initialize` request.
type InitializeRequestArguments struct {
ClientID string `json:"clientID,omitempty"`
ClientName string `json:"clientName,omitempty"`
AdapterID string `json:"adapterID"`
Locale string `json:"locale,omitempty"`
LinesStartAt1 bool `json:"linesStartAt1"`
ColumnsStartAt1 bool `json:"columnsStartAt1"`
PathFormat string `json:"pathFormat,omitempty"`
SupportsVariableType bool `json:"supportsVariableType,omitempty"`
SupportsVariablePaging bool `json:"supportsVariablePaging,omitempty"`
SupportsRunInTerminalRequest bool `json:"supportsRunInTerminalRequest,omitempty"`
SupportsMemoryReferences bool `json:"supportsMemoryReferences,omitempty"`
SupportsProgressReporting bool `json:"supportsProgressReporting,omitempty"`
SupportsInvalidatedEvent bool `json:"supportsInvalidatedEvent,omitempty"`
SupportsMemoryEvent bool `json:"supportsMemoryEvent,omitempty"`
SupportsArgsCanBeInterpretedByShell bool `json:"supportsArgsCanBeInterpretedByShell,omitempty"`
SupportsStartDebuggingRequest bool `json:"supportsStartDebuggingRequest,omitempty"`
}
// InitializeResponse: Response to `initialize` request.
type InitializeResponse struct {
Response
Body Capabilities `json:"body,omitempty"`
}
// ConfigurationDoneRequest: This request indicates that the client has finished initialization of the debug adapter.
// So it is the last request in the sequence of configuration requests (which was started by the `initialized` event).
// Clients should only call this request if the corresponding capability `supportsConfigurationDoneRequest` is true.
type ConfigurationDoneRequest struct {
Request
Arguments *ConfigurationDoneArguments `json:"arguments,omitempty"`
}
// ConfigurationDoneArguments: Arguments for `configurationDone` request.
type ConfigurationDoneArguments struct {
}
// ConfigurationDoneResponse: Response to `configurationDone` request. This is just an acknowledgement, so no body field is required.
type ConfigurationDoneResponse struct {
Response
}
// LaunchRequest: This launch request is sent from the client to the debug adapter to start the debuggee with or without debugging (if `noDebug` is true).
// Since launching is debugger/runtime specific, the arguments for this request are not part of this specification.
type LaunchRequest struct {
Request
Arguments json.RawMessage `json:"arguments"`
}
func (r *LaunchRequest) GetArguments() json.RawMessage { return r.Arguments }
// LaunchResponse: Response to `launch` request. This is just an acknowledgement, so no body field is required.
type LaunchResponse struct {
Response
}
// AttachRequest: The `attach` request is sent from the client to the debug adapter to attach to a debuggee that is already running.
// Since attaching is debugger/runtime specific, the arguments for this request are not part of this specification.
type AttachRequest struct {
Request
Arguments json.RawMessage `json:"arguments"`
}
func (r *AttachRequest) GetArguments() json.RawMessage { return r.Arguments }
// AttachResponse: Response to `attach` request. This is just an acknowledgement, so no body field is required.
type AttachResponse struct {
Response
}
// RestartRequest: Restarts a debug session. Clients should only call this request if the corresponding capability `supportsRestartRequest` is true.
// If the capability is missing or has the value false, a typical client emulates `restart` by terminating the debug adapter first and then launching it anew.
type RestartRequest struct {
Request
Arguments json.RawMessage `json:"arguments"`
}
// RestartResponse: Response to `restart` request. This is just an acknowledgement, so no body field is required.
type RestartResponse struct {
Response
}
// DisconnectRequest: The `disconnect` request asks the debug adapter to disconnect from the debuggee (thus ending the debug session) and then to shut down itself (the debug adapter).
// In addition, the debug adapter must terminate the debuggee if it was started with the `launch` request. If an `attach` request was used to connect to the debuggee, then the debug adapter must not terminate the debuggee.
// This implicit behavior of when to terminate the debuggee can be overridden with the `terminateDebuggee` argument (which is only supported by a debug adapter if the corresponding capability `supportTerminateDebuggee` is true).
type DisconnectRequest struct {
Request
Arguments *DisconnectArguments `json:"arguments,omitempty"`
}
// DisconnectArguments: Arguments for `disconnect` request.
type DisconnectArguments struct {
Restart bool `json:"restart,omitempty"`
TerminateDebuggee bool `json:"terminateDebuggee,omitempty"`
SuspendDebuggee bool `json:"suspendDebuggee,omitempty"`
}
// DisconnectResponse: Response to `disconnect` request. This is just an acknowledgement, so no body field is required.
type DisconnectResponse struct {
Response
}
// TerminateRequest: The `terminate` request is sent from the client to the debug adapter in order to shut down the debuggee gracefully. Clients should only call this request if the capability `supportsTerminateRequest` is true.
// Typically a debug adapter implements `terminate` by sending a software signal which the debuggee intercepts in order to clean things up properly before terminating itself.
// Please note that this request does not directly affect the state of the debug session: if the debuggee decides to veto the graceful shutdown for any reason by not terminating itself, then the debug session just continues.
// Clients can surface the `terminate` request as an explicit command or they can integrate it into a two stage Stop command that first sends `terminate` to request a graceful shutdown, and if that fails uses `disconnect` for a forceful shutdown.
type TerminateRequest struct {
Request
Arguments *TerminateArguments `json:"arguments,omitempty"`
}
// TerminateArguments: Arguments for `terminate` request.
type TerminateArguments struct {
Restart bool `json:"restart,omitempty"`
}
// TerminateResponse: Response to `terminate` request. This is just an acknowledgement, so no body field is required.
type TerminateResponse struct {
Response
}
// BreakpointLocationsRequest: The `breakpointLocations` request returns all possible locations for source breakpoints in a given range.
// Clients should only call this request if the corresponding capability `supportsBreakpointLocationsRequest` is true.
type BreakpointLocationsRequest struct {
Request
Arguments *BreakpointLocationsArguments `json:"arguments,omitempty"`
}
// BreakpointLocationsArguments: Arguments for `breakpointLocations` request.
type BreakpointLocationsArguments struct {
Source Source `json:"source"`
Line int `json:"line"`
Column int `json:"column,omitempty"`
EndLine int `json:"endLine,omitempty"`
EndColumn int `json:"endColumn,omitempty"`
}
// BreakpointLocationsResponse: Response to `breakpointLocations` request.
// Contains possible locations for source breakpoints.
type BreakpointLocationsResponse struct {
Response
Body BreakpointLocationsResponseBody `json:"body"`
}
type BreakpointLocationsResponseBody struct {
Breakpoints []BreakpointLocation `json:"breakpoints"`
}
// SetBreakpointsRequest: Sets multiple breakpoints for a single source and clears all previous breakpoints in that source.
// To clear all breakpoint for a source, specify an empty array.
// When a breakpoint is hit, a `stopped` event (with reason `breakpoint`) is generated.
type SetBreakpointsRequest struct {
Request
Arguments SetBreakpointsArguments `json:"arguments"`
}
// SetBreakpointsArguments: Arguments for `setBreakpoints` request.
type SetBreakpointsArguments struct {
Source Source `json:"source"`
Breakpoints []SourceBreakpoint `json:"breakpoints,omitempty"`
Lines []int `json:"lines,omitempty"`
SourceModified bool `json:"sourceModified,omitempty"`
}
// SetBreakpointsResponse: Response to `setBreakpoints` request.
// Returned is information about each breakpoint created by this request.
// This includes the actual code location and whether the breakpoint could be verified.
// The breakpoints returned are in the same order as the elements of the `breakpoints`
// (or the deprecated `lines`) array in the arguments.
type SetBreakpointsResponse struct {
Response
Body SetBreakpointsResponseBody `json:"body"`
}
type SetBreakpointsResponseBody struct {
Breakpoints []Breakpoint `json:"breakpoints"`
}
// SetFunctionBreakpointsRequest: Replaces all existing function breakpoints with new function breakpoints.
// To clear all function breakpoints, specify an empty array.
// When a function breakpoint is hit, a `stopped` event (with reason `function breakpoint`) is generated.
// Clients should only call this request if the corresponding capability `supportsFunctionBreakpoints` is true.
type SetFunctionBreakpointsRequest struct {
Request
Arguments SetFunctionBreakpointsArguments `json:"arguments"`
}
// SetFunctionBreakpointsArguments: Arguments for `setFunctionBreakpoints` request.
type SetFunctionBreakpointsArguments struct {
Breakpoints []FunctionBreakpoint `json:"breakpoints"`
}
// SetFunctionBreakpointsResponse: Response to `setFunctionBreakpoints` request.
// Returned is information about each breakpoint created by this request.
type SetFunctionBreakpointsResponse struct {
Response
Body SetFunctionBreakpointsResponseBody `json:"body"`
}
type SetFunctionBreakpointsResponseBody struct {
Breakpoints []Breakpoint `json:"breakpoints"`
}
// SetExceptionBreakpointsRequest: The request configures the debugger's response to thrown exceptions.
// If an exception is configured to break, a `stopped` event is fired (with reason `exception`).
// Clients should only call this request if the corresponding capability `exceptionBreakpointFilters` returns one or more filters.
type SetExceptionBreakpointsRequest struct {
Request
Arguments SetExceptionBreakpointsArguments `json:"arguments"`
}
// SetExceptionBreakpointsArguments: Arguments for `setExceptionBreakpoints` request.
type SetExceptionBreakpointsArguments struct {
Filters []string `json:"filters"`
FilterOptions []ExceptionFilterOptions `json:"filterOptions,omitempty"`
ExceptionOptions []ExceptionOptions `json:"exceptionOptions,omitempty"`
}
// SetExceptionBreakpointsResponse: Response to `setExceptionBreakpoints` request.
// The response contains an array of `Breakpoint` objects with information about each exception breakpoint or filter. The `Breakpoint` objects are in the same order as the elements of the `filters`, `filterOptions`, `exceptionOptions` arrays given as arguments. If both `filters` and `filterOptions` are given, the returned array must start with `filters` information first, followed by `filterOptions` information.
// The `verified` property of a `Breakpoint` object signals whether the exception breakpoint or filter could be successfully created and whether the condition or hit count expressions are valid. In case of an error the `message` property explains the problem. The `id` property can be used to introduce a unique ID for the exception breakpoint or filter so that it can be updated subsequently by sending breakpoint events.
// For backward compatibility both the `breakpoints` array and the enclosing `body` are optional. If these elements are missing a client is not able to show problems for individual exception breakpoints or filters.
type SetExceptionBreakpointsResponse struct {
Response
Body SetExceptionBreakpointsResponseBody `json:"body,omitempty"`
}
type SetExceptionBreakpointsResponseBody struct {
Breakpoints []Breakpoint `json:"breakpoints,omitempty"`
}
// DataBreakpointInfoRequest: Obtains information on a possible data breakpoint that could be set on an expression or variable.
// Clients should only call this request if the corresponding capability `supportsDataBreakpoints` is true.
type DataBreakpointInfoRequest struct {
Request
Arguments DataBreakpointInfoArguments `json:"arguments"`
}
// DataBreakpointInfoArguments: Arguments for `dataBreakpointInfo` request.
type DataBreakpointInfoArguments struct {
VariablesReference int `json:"variablesReference,omitempty"`
Name string `json:"name"`
FrameId int `json:"frameId,omitempty"`
}
// DataBreakpointInfoResponse: Response to `dataBreakpointInfo` request.
type DataBreakpointInfoResponse struct {
Response
Body DataBreakpointInfoResponseBody `json:"body"`
}
type DataBreakpointInfoResponseBody struct {
DataId any `json:"dataId"`
Description string `json:"description"`
AccessTypes []DataBreakpointAccessType `json:"accessTypes,omitempty"`
CanPersist bool `json:"canPersist,omitempty"`
}
// SetDataBreakpointsRequest: Replaces all existing data breakpoints with new data breakpoints.
// To clear all data breakpoints, specify an empty array.
// When a data breakpoint is hit, a `stopped` event (with reason `data breakpoint`) is generated.
// Clients should only call this request if the corresponding capability `supportsDataBreakpoints` is true.
type SetDataBreakpointsRequest struct {
Request
Arguments SetDataBreakpointsArguments `json:"arguments"`
}
// SetDataBreakpointsArguments: Arguments for `setDataBreakpoints` request.
type SetDataBreakpointsArguments struct {
Breakpoints []DataBreakpoint `json:"breakpoints"`
}
// SetDataBreakpointsResponse: Response to `setDataBreakpoints` request.
// Returned is information about each breakpoint created by this request.
type SetDataBreakpointsResponse struct {
Response
Body SetDataBreakpointsResponseBody `json:"body"`
}
type SetDataBreakpointsResponseBody struct {
Breakpoints []Breakpoint `json:"breakpoints"`
}
// SetInstructionBreakpointsRequest: Replaces all existing instruction breakpoints. Typically, instruction breakpoints would be set from a disassembly window.
// To clear all instruction breakpoints, specify an empty array.
// When an instruction breakpoint is hit, a `stopped` event (with reason `instruction breakpoint`) is generated.
// Clients should only call this request if the corresponding capability `supportsInstructionBreakpoints` is true.
type SetInstructionBreakpointsRequest struct {
Request
Arguments SetInstructionBreakpointsArguments `json:"arguments"`
}
// SetInstructionBreakpointsArguments: Arguments for `setInstructionBreakpoints` request
type SetInstructionBreakpointsArguments struct {
Breakpoints []InstructionBreakpoint `json:"breakpoints"`
}
// SetInstructionBreakpointsResponse: Response to `setInstructionBreakpoints` request
type SetInstructionBreakpointsResponse struct {
Response
Body SetInstructionBreakpointsResponseBody `json:"body"`
}
type SetInstructionBreakpointsResponseBody struct {
Breakpoints []Breakpoint `json:"breakpoints"`
}
// ContinueRequest: The request resumes execution of all threads. If the debug adapter supports single thread execution (see capability `supportsSingleThreadExecutionRequests`), setting the `singleThread` argument to true resumes only the specified thread. If not all threads were resumed, the `allThreadsContinued` attribute of the response should be set to false.
type ContinueRequest struct {
Request
Arguments ContinueArguments `json:"arguments"`
}
// ContinueArguments: Arguments for `continue` request.
type ContinueArguments struct {
ThreadId int `json:"threadId"`
SingleThread bool `json:"singleThread,omitempty"`
}
// ContinueResponse: Response to `continue` request.
type ContinueResponse struct {
Response
Body ContinueResponseBody `json:"body"`
}
type ContinueResponseBody struct {
AllThreadsContinued bool `json:"allThreadsContinued"`
}
// NextRequest: The request executes one step (in the given granularity) for the specified thread and allows all other threads to run freely by resuming them.
// If the debug adapter supports single thread execution (see capability `supportsSingleThreadExecutionRequests`), setting the `singleThread` argument to true prevents other suspended threads from resuming.
// The debug adapter first sends the response and then a `stopped` event (with reason `step`) after the step has completed.
type NextRequest struct {
Request
Arguments NextArguments `json:"arguments"`
}
// NextArguments: Arguments for `next` request.
type NextArguments struct {
ThreadId int `json:"threadId"`
SingleThread bool `json:"singleThread,omitempty"`
Granularity SteppingGranularity `json:"granularity,omitempty"`
}
// NextResponse: Response to `next` request. This is just an acknowledgement, so no body field is required.
type NextResponse struct {
Response
}
// StepInRequest: The request resumes the given thread to step into a function/method and allows all other threads to run freely by resuming them.
// If the debug adapter supports single thread execution (see capability `supportsSingleThreadExecutionRequests`), setting the `singleThread` argument to true prevents other suspended threads from resuming.
// If the request cannot step into a target, `stepIn` behaves like the `next` request.
// The debug adapter first sends the response and then a `stopped` event (with reason `step`) after the step has completed.
// If there are multiple function/method calls (or other targets) on the source line,
// the argument `targetId` can be used to control into which target the `stepIn` should occur.
// The list of possible targets for a given source line can be retrieved via the `stepInTargets` request.
type StepInRequest struct {
Request
Arguments StepInArguments `json:"arguments"`
}
// StepInArguments: Arguments for `stepIn` request.
type StepInArguments struct {
ThreadId int `json:"threadId"`
SingleThread bool `json:"singleThread,omitempty"`
TargetId int `json:"targetId,omitempty"`
Granularity SteppingGranularity `json:"granularity,omitempty"`
}
// StepInResponse: Response to `stepIn` request. This is just an acknowledgement, so no body field is required.
type StepInResponse struct {
Response
}
// StepOutRequest: The request resumes the given thread to step out (return) from a function/method and allows all other threads to run freely by resuming them.
// If the debug adapter supports single thread execution (see capability `supportsSingleThreadExecutionRequests`), setting the `singleThread` argument to true prevents other suspended threads from resuming.
// The debug adapter first sends the response and then a `stopped` event (with reason `step`) after the step has completed.
type StepOutRequest struct {
Request
Arguments StepOutArguments `json:"arguments"`
}
// StepOutArguments: Arguments for `stepOut` request.
type StepOutArguments struct {
ThreadId int `json:"threadId"`
SingleThread bool `json:"singleThread,omitempty"`
Granularity SteppingGranularity `json:"granularity,omitempty"`
}
// StepOutResponse: Response to `stepOut` request. This is just an acknowledgement, so no body field is required.
type StepOutResponse struct {
Response
}
// StepBackRequest: The request executes one backward step (in the given granularity) for the specified thread and allows all other threads to run backward freely by resuming them.
// If the debug adapter supports single thread execution (see capability `supportsSingleThreadExecutionRequests`), setting the `singleThread` argument to true prevents other suspended threads from resuming.
// The debug adapter first sends the response and then a `stopped` event (with reason `step`) after the step has completed.
// Clients should only call this request if the corresponding capability `supportsStepBack` is true.
type StepBackRequest struct {
Request
Arguments StepBackArguments `json:"arguments"`
}
// StepBackArguments: Arguments for `stepBack` request.
type StepBackArguments struct {
ThreadId int `json:"threadId"`
SingleThread bool `json:"singleThread,omitempty"`
Granularity SteppingGranularity `json:"granularity,omitempty"`
}
// StepBackResponse: Response to `stepBack` request. This is just an acknowledgement, so no body field is required.
type StepBackResponse struct {
Response
}
// ReverseContinueRequest: The request resumes backward execution of all threads. If the debug adapter supports single thread execution (see capability `supportsSingleThreadExecutionRequests`), setting the `singleThread` argument to true resumes only the specified thread. If not all threads were resumed, the `allThreadsContinued` attribute of the response should be set to false.
// Clients should only call this request if the corresponding capability `supportsStepBack` is true.
type ReverseContinueRequest struct {
Request
Arguments ReverseContinueArguments `json:"arguments"`
}
// ReverseContinueArguments: Arguments for `reverseContinue` request.
type ReverseContinueArguments struct {
ThreadId int `json:"threadId"`
SingleThread bool `json:"singleThread,omitempty"`
}
// ReverseContinueResponse: Response to `reverseContinue` request. This is just an acknowledgement, so no body field is required.
type ReverseContinueResponse struct {
Response
}
// RestartFrameRequest: The request restarts execution of the specified stack frame.
// The debug adapter first sends the response and then a `stopped` event (with reason `restart`) after the restart has completed.
// Clients should only call this request if the corresponding capability `supportsRestartFrame` is true.
type RestartFrameRequest struct {
Request
Arguments RestartFrameArguments `json:"arguments"`
}
// RestartFrameArguments: Arguments for `restartFrame` request.
type RestartFrameArguments struct {
FrameId int `json:"frameId"`
}
// RestartFrameResponse: Response to `restartFrame` request. This is just an acknowledgement, so no body field is required.
type RestartFrameResponse struct {
Response
}
// GotoRequest: The request sets the location where the debuggee will continue to run.
// This makes it possible to skip the execution of code or to execute code again.
// The code between the current location and the goto target is not executed but skipped.
// The debug adapter first sends the response and then a `stopped` event with reason `goto`.
// Clients should only call this request if the corresponding capability `supportsGotoTargetsRequest` is true (because only then goto targets exist that can be passed as arguments).
type GotoRequest struct {
Request
Arguments GotoArguments `json:"arguments"`
}
// GotoArguments: Arguments for `goto` request.
type GotoArguments struct {
ThreadId int `json:"threadId"`
TargetId int `json:"targetId"`
}
// GotoResponse: Response to `goto` request. This is just an acknowledgement, so no body field is required.
type GotoResponse struct {
Response
}
// PauseRequest: The request suspends the debuggee.
// The debug adapter first sends the response and then a `stopped` event (with reason `pause`) after the thread has been paused successfully.
type PauseRequest struct {
Request
Arguments PauseArguments `json:"arguments"`
}
// PauseArguments: Arguments for `pause` request.
type PauseArguments struct {
ThreadId int `json:"threadId"`
}
// PauseResponse: Response to `pause` request. This is just an acknowledgement, so no body field is required.
type PauseResponse struct {
Response
}
// StackTraceRequest: The request returns a stacktrace from the current execution state of a given thread.
// A client can request all stack frames by omitting the startFrame and levels arguments. For performance-conscious clients and if the corresponding capability `supportsDelayedStackTraceLoading` is true, stack frames can be retrieved in a piecemeal way with the `startFrame` and `levels` arguments. The response of the `stackTrace` request may contain a `totalFrames` property that hints at the total number of frames in the stack. If a client needs this total number upfront, it can issue a request for a single (first) frame and depending on the value of `totalFrames` decide how to proceed. In any case a client should be prepared to receive fewer frames than requested, which is an indication that the end of the stack has been reached.
type StackTraceRequest struct {
Request
Arguments StackTraceArguments `json:"arguments"`
}
// StackTraceArguments: Arguments for `stackTrace` request.
type StackTraceArguments struct {
ThreadId int `json:"threadId"`
StartFrame int `json:"startFrame,omitempty"`
Levels int `json:"levels,omitempty"`
Format *StackFrameFormat `json:"format,omitempty"`
}
// StackTraceResponse: Response to `stackTrace` request.
type StackTraceResponse struct {
Response
Body StackTraceResponseBody `json:"body"`
}
type StackTraceResponseBody struct {
StackFrames []StackFrame `json:"stackFrames"`
TotalFrames int `json:"totalFrames,omitempty"`
}
// ScopesRequest: The request returns the variable scopes for a given stack frame ID.
type ScopesRequest struct {
Request
Arguments ScopesArguments `json:"arguments"`
}
// ScopesArguments: Arguments for `scopes` request.
type ScopesArguments struct {
FrameId int `json:"frameId"`
}