Allow display of local variables in frames multiple levels deep.

[brownts]

Fixes #342.

Remove the arbitrary separation between the variable references used
to represent scopes and those used to represent variable objects.
This implementation uses a common pool of handles to support both
variable object references as well as scope references, thus
eliminating the previous bounded numerical range used for scopes,
which was not large enough to represent stack frames multiple levels
deep, due to thread and level information being encoded in the scope
variable reference value.

[GitMensch]

Looks good to me in general. Things I'm not sure about:

1. Shouldn't there be more than the "Local" scope?
2. Is it possible to use the scope from the DAP here instead of an own class?

[GitMensch]

See #242 for how to acquire variables for the Register scope, which would be a possible follow-up to this change.

[brownts]

1. Shouldn't there be more than the "Local" scope?

The current implementation only supports the "Local" scope. Additional scopes could be added, but this PR is to address a bug in the current implementation. I'd rather keep bug fixes and new functionality separate, from a semantic versioning perspective, as bug fixes can go into patch releases (e.g., 0.26.1), but new functionality should go into a minor release (e.g., 0.27.0). It seems there are other open issues (e.g., #214) to capture adding an additional scope.

2. Is it possible to use the scope from the DAP here instead of an own class?

I assume you are referring to the addition of the VariableScope class. That class is used to map the scope name, debugger thread and stack frame level to the corresponding variablesReference value that is supplied in the DAP Scope response (see return value of MI2DebugSession::scopesRequest::createScope for how this information is used to map to the variablesReference supplied in the DAP Scope response). The previous implementation attempted to encode the debugger's thread and level directly into the variablesReference in the DAP Scope response, but when stack levels were deep enough the encoded value clashed with the variablesReference numerical space used to represent variables.

So, to answer your question, the DAP Scope is used (as stated above), but the VariableScope is used to hold additional internal information (i.e., thread id, stack frame level) that is not directly represented in the DAP Scope response.

[WebFreak001]

I like the change, can you check out my two comments?

[GitMensch]

I'd rather keep bug fixes and new functionality separate, from a semantic versioning perspective, as bug fixes can go into patch releases (e.g., 0.26.1), but new functionality should go into a minor release (e.g., 0.27.0)

Of course new minor versions can/should also include bug fixes ;-)

I think for 0.26.1 #346 and possibly #332 are the open points, before going on to bigger changes. @brownts I guess you don't want to include #330 soon, do you?
#347 would be useful at any time, @WebFreak001 are you working on this or is it mainly a point on the TODO list?

[WebFreak001]

@GitMensch it's just a point on the TODO list, I haven't really touched code-debug code in a while

[brownts]

In reference to #347, I do have a unit test github action that I created locally to run the existing unit tests for my own testing, but hadn't pushed it yet. I can create a PR for that soon. I haven't done anything towards an integration test though.

[GitMensch]

Sounds good! Please do so and let's discuss automated testing in that PR or the referenced issue.

[brownts]

Also, to follow-up on your other question, I haven't done much on #330 yet, so it's not ready to go into a near-term release.

[GitMensch]

In reference to #347, I do have a unit test github action that I created locally to run the existing unit tests for my own testing, but hadn't pushed it yet. I can create a PR for that soon. I haven't done anything towards an integration test though.

@brownts: was the unit testing part already pushed with the sourceFileMap changes today or are there more? In any case: can you please PR the unit testing GH action you already have?