Support object inspection through DAP

[rsubtil]

Closes #97182.

Implements object inspection through DAP. All object properties are bundled in Categories for organization, similarly to what is shown from Godot:

Object inspection is done in a lazy fashion, as the performance impact of querying them is quite significant. DAP IDs are generated for detected object types when parsing Variants, and information is only requested from the debuggee when an explicit variables request is made.

[Faless]

Looking good, please see changes to avoid including std:optional.

As @AThousandShips pointed out, we might also want to remove the lambdas too (though there are some use in other editor code, we still try to avoid them, especially in combination with auto).

Resolved

[Faless]

LGTM 👍 , nice work!

[van800]

Awesome!
I have tried it a little bit.
It works great for variables request, as your mentioned.
I wonder, why have you decided to not enable it for evaluate requests?

[rsubtil]

I wonder, why have you decided to not enable it for evaluate requests?

Whoops, I forgot about the evaluate request, I'm sorry 😅

This one is a bit trickier because Godot receives a plain string to evaluate, rather than a variable ID. This exists already for evaluating script tokens, so the result is the same here from Godot (the cursor isn't visible, but it is hovering the self token at line 11):

But I can actually easily store this mapping between variable name and DAP variable ID when the stack frame is being parsed, so it shouldn't be difficult to support this. So, while the result string would stay the same, the variablesReference would now point to a valid ID, which I assume IDEs will then use to generate a variables request for more info.

[van800]

Sure, I would be willing to test.

Evaluate is not only for hovering but also for expression evaluation. Like in "Watch" in vscode or similar in Rider.

Unfortunately I don't know how to configure vscode to use DAP for a proper comparison.

[rsubtil]

Turned out to be simple indeed; I've implemented support for it when an evaluated variable has been parsed, please test to see if behavior is correct now. VSCode seems to be working correctly:

Unfortunately I don't know how to configure vscode to use DAP for a proper comparison.

You can check this guide in the docs on how to set up LSP/DAP support on VSCode.

[van800]

Please try to evaluate expression in vscode:

I confirm that evaluating self now works, but the self.position expression evaluates to empty string (left-bottom corner).
Special thanks for linking the guide, now I am using it.

[rsubtil]

I confirm that evaluating self now works, but the self.position expression evaluates to empty string (left-bottom corner).

As it's currently implemented, the evaluate expression only looks at any existing variable that matches the requested content. self.position is not a variable, and so it returns empty.

What you're asking for is REPL, which Godot doesn't support... yet; there's some activity around it, like #60134 (and #97647 which was open... just 4 hours ago 😁)

[van800]

Interestingly, evaluating expressions almost works in VS Code when using legacy non-DAP mode, which led me to believe it could be added to DAP mode as well. That said, I’m very happy with this pull request regardless.

[rsubtil]

I see. I had a quick peek at the VSCode plugin, and keeping in mind I'm not familiarized with the codebase at all, I'd wager it is building an internal tree of variables when variable information comes, which is then used for this scenario when there is a variable access. So, it is something the addon itself is doing, and not Godot.

Again, I can be completely wrong here, but if that's what the addon does, instead of replicating this from Godot, I'd wait to see if REPL functionality is implemented in the meantime, as it is a much better solution for this.

EDIT: Ok, the PR I talked about was merged an hour ago, lol 🎉. I'll have a look to see if it can use this new system.

[akien-mga]

Does the above discussion imply that you'd prefer to do further work here @rsubtil based on #97647, or is that for follow-up work / specific to the VS code extension?

[rsubtil]

Does the above discussion imply that you'd prefer to do further work here @rsubtil based on #97647, or is that for follow-up work / specific to the VS code extension?

This would replace the changes I did in the meantime for the evaluate request, so I think it's worth it to replace them already with this new system. I also don't expect this to be difficult, and should be ready in the next coming days.

[rsubtil]

I've changed the evaluate request to go through the new REPL system, so more advanced expressions should work properly now:

Since these two requests require information from the debuggee, I've also increased the default timeout from 1 to 5 seconds to give it more "breathing room" when having to complete potentially heavy requests.

[van800]

Great! Tried it in Rider and VScode.

Out of scope, but I'd rather ask, if Completions Request from the spec is not implemented, right?
It made it hard to figure out that why evaluation self.path was null, while I should have called self.get_path().

[akien-mga]

Great work as usual! Thanks for your dedication to maintaining the DAP support!