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
// This file is autogenerated. Do not edit by hand.
// To regenerate from schema, run `cargo run -p generator`.
pub use crateIEvent;
/// The event indicates that some information about a breakpoint has changed.
///
/// See [BreakpointEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Breakpoint)
/// 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.
///
/// See [CapabilitiesEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Capabilities)
/// 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.
///
/// See [ContinuedEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Continued)
/// The event indicates that the debuggee has exited and returns its exit code.
///
/// See [ExitedEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Exited)
/// 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.
///
/// See [InitializedEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Initialized)
/// 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.
///
/// See [InvalidatedEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Invalidated)
/// The event indicates that some source has been added, changed, or removed from the set of all loaded sources.
///
/// See [LoadedSourceEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_LoadedSource)
/// 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.
///
/// See [MemoryEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Memory)
/// The event indicates that some information about a module has changed.
///
/// See [ModuleEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Module)
/// The event indicates that the target has produced some output.
///
/// See [OutputEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Output)
/// 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.
///
/// See [ProcessEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Process)
/// 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.
///
/// See [ProgressEndEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_ProgressEnd)
/// 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.
///
/// See [ProgressStartEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_ProgressStart)
/// 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.
///
/// See [ProgressUpdateEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_ProgressUpdate)
/// 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.
///
/// See [StoppedEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Stopped)
/// The event indicates that debugging of the debuggee has terminated. This does **not** mean that the debuggee itself has exited.
///
/// See [TerminatedEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Terminated)
/// The event indicates that a thread has started or exited.
///
/// See [ThreadEvent](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Thread)