dap: implement variable references #3307
Conversation
jsternberg
force-pushed
the
dap-variables
branch
from
724efc8 to
30e5469
Compare
| Name: "platform", | ||
| Value: fmt.Sprintf("%s/%s", platform.OS, platform.Architecture), | ||
| VariablesReference: refs.New(func() []dap.Variable { | ||
| vars := []dap.Variable{ |
There was a problem hiding this comment.
Why split these apart? They are also part of the same field when configuring build.
There was a problem hiding this comment.
It ends up looking like this. So the first value is the "summary value" and then you can click further in and get individual variables.
| Name: "args", | ||
| Value: brief(strings.Join(exec.Meta.Args, " ")), | ||
| VariablesReference: refs.New(func() []dap.Variable { | ||
| vars := make([]dap.Variable, 0, len(exec.Meta.Args)) |
There was a problem hiding this comment.
Maybe missing something but why are args split into separate vars?
There was a problem hiding this comment.
It's so they show up in the debugger like this:
That way you can directly inspect the specific indexes of the array.
| } | ||
|
|
||
| varRef := req.Arguments.VariablesReference & ((1 << 24) - 1) | ||
| resp.Body.Variables = t.Variables(varRef) |
There was a problem hiding this comment.
I think it's safe to set an empty slice (make([]dap.Variable, 0)) as the default value to avoid being marshalled to null (related discussion: mfussenegger/nvim-dap#225 )
|
|
||
| resp.Body.Scopes = t.Scopes(req.Arguments.FrameId) | ||
| for i, s := range resp.Body.Scopes { | ||
| resp.Body.Scopes[i].VariablesReference = (t.id << 24) | s.VariablesReference |
There was a problem hiding this comment.
Shouldn't we check the overflow?
There was a problem hiding this comment.
I guess we can but I figure this is probably pretty low risk and it would just create some weird UI artifacts if there was an accidental conflict.
The main reason for this is because I haven't created a way where the threads will synchronize on pause and I didn't want to micromanage the variable references in a global container. This isn't currently an issue since, with build, there will only ever be one thread. But, since we want to add support for bake debugging too, we'll either need to allow multiple threads to exist or to synchronize them.
I figure the only way this overflows is if there are over 256 targets (only possible with bake) or over 2^24 variables (16,777,216). I figure if you're debugging something with these numbers you'll probably break the UI first.
jsternberg
force-pushed
the
dap-variables
branch
from
30e5469 to
f52370a
Compare
Implement variable references to inspect the state of a stack frame. Variable reference ids are composed of two sections. A thread mask that is the first 8 bytes and the remainder is an increasing number that gets reset each time a thread is resumed. This allows the adapter to know which thread to delegate the variables request to and allows the variable references to still remain confined to each thread. An int32 is used for this because variable references need to be in the range of (0, 2^32). At the moment, only the platform variables and some of the exec operations for an operation. These are labeled as "arguments" to the stack frame. Signed-off-by: Jonathan A. Sternberg <[email protected]>
jsternberg
force-pushed
the
dap-variables
branch
from
f52370a to
1886e23
Compare
3 participants
Implement variable references to inspect the state of a stack frame.
Variable reference ids are composed of two sections. A thread mask that
is the first 8 bytes and the remainder is an increasing number that gets
reset each time a thread is resumed. This allows the adapter to know
which thread to delegate the variables request to and allows the
variable references to still remain confined to each thread. An int32 is
used for this because variable references need to be in the range of
(0, 2^32).
At the moment, only the platform variables and some of the exec
operations for an operation. These are labeled as "arguments" to the
stack frame.