Clarify impact of StackFrameFormat

[tromey]

While working on the gdb implementation of DAP, I wasn't sure what to do with StackFrameFormat -- in particular, what impact it ought to have.

My guess is that many of the parameters ought to affect the name of the returned stack frame. It would be great if the spec could spell this out.

Some parameters, like line and module, seem redundant, though. And even parameterValues seems redundant with the scopes request.

[connor4312]

I'm not sure actually. @gregg-miskelly do you have historical context on this one?

[gregg-miskelly]

My guess is that many of the parameters ought to affect the name of the returned stack frame. It would be great if the spec could spell this out.

Correct

Some parameters, like line and module, seem redundant, though. And even parameterValues seems redundant with the scopes request.

By "redundant" do you mean the client could produce the name itself in some way? If so, that is correct, but it is done this way so that:

1. The debug adapter can format the string in a syntax that makes sense in their language
   -and-
2. The debug adapter may be able to far more efficiently produce the value of just the arguments to the function than the using a scopes request

[tromey]

By "redundant" do you mean the client could produce the name itself in some way?

I just meant that the line and module are already present in the StackFrame, so I didn't understand if this flag means the client is required to also put the information into name.

[connor4312]

Thanks for the context. I suggest replacing "for the stack frame" to "in the StackFrame.name" for the relevant properties.

[tromey]

A related question here is what does parameters mean -- how does it differ from parameterTypes, parameterNames, and parameterValues?

[gregg-miskelly]

I think it was a mistake to include parameters. I believe the author of this part of the spec was borrowing too heavily from Visual Studio's debug interface (FIF_FUNCNAME_ARGS) but here is how I believe this was intended to work:

• parameters == false: Don't indicate anything about the parameters to the method. Debugger doesn't need to even look at parameterTypes, parameterNames or parameterValues
• parameters == true: Include the arguments in a way that makes sense for the language being debugged, using parameterTypes, parameterNames, and parameterValues as makes sense

[JustinGrote]

Sorry to necro this thread, but I was curious in regards to the parameters surfacing, what about the actual values/arguments specified to those parameters?

For example if I have this call stack:

Not sure where I am supposed to surface those Argument values, since it's not a property on the StackTrace itself or the Source