Investigate into using language service support for scope resolution

[weinand]

Related Issues:

• Debug hover does not use AST Debug hover does not use AST #24520
• Debug Hover Box don't show up even in the right scope Inspect Protocol - Debug Hover Box don't show up even in the right scope #37838
• Inline values are shown for a variable in different scope if it has same name in current scope Inline values are shown for a variable in different scope if it has same name in current scope #19215

Examples of bogus behavior:

[weinand]

VS Code's hover functionality suffers from some problems:

• if different variables have the same name in different scopes, VS Code does not always show the correct value.
• if the source language is not the same as the target language, hovering over variables does not show a value at all.
• hovering over a complex variable path (e.g. "doc->foo[123]") does not show correct values or values at all.

These issues are a consequence of VS Code's generic hover implementation and insufficient implementations of specific debug extension/adapters.

VS Code's generic hover implementation makes use of some language agnostic heuristics:

• VS Code uses a simple regular expression to find the hovered expression under the mouse. E.g. the index operator "[123]" in "doc->foo[123]" is not detected. In addition this regular expression is not contributed by the source language.
• When hovering over source text, most variables detected via the regular expression from above are actually "false positives" because they are "out of scope" with respect to the current execution context (stackframe). In order to avoid showing hovers for them, VS Code uses the source code ranges in DAP's StackFrame and Scope objects. Since this range information is of bad quality, VS Code ignores them for hovers but uses them when showing inline values (this results in the problem shown in the initial comment from above).
• depending on some capability of the debug adapter VS Code uses one of two strategies for finding the value of a variable under the mouse:
  • the variable name is matched against the variables in VS Code's VARIABLES view.
  • the variable name is used as an expression that is evaluated via the debug adapter's "evaluate" request.

I propose the following improvements:

• introduce new API for finding the debug specific expression for a given source location (= hover location). VS Code would use this API in favour of its builtin regular expression. At the moment it is not clear whether this API lives on a language extension or on the DAP. In the latter case the debug adapter would need new (reverse) DAP API to delegate this request back to the language service in the client. The advantage of the latter approach is that the debug adapter has a chance to modify the expression returned from the language service so it can be used by an upcoming "evaluate" request.
• introduce new (reverse) DAP API so that a debug adapter can get scope range information from its client (e.g. VS Code). The debug adapter could use this API to provide correct range information in DAP Scope and Frame objects returned to the client. This helps the client to know the correct scope of a variable.
• introduce new (reverse) DAP API so that a debug adapter can map variable names between target and source languages. This makes it possible that a debug adapter can return DAP Variable objects with source names (instead of target names like it does today).

[weinand]

Since this is an investigation there is nothing to verify or test for now.

[weinand]

Reopened for continuing work in Dec/Jan...

[gjsjohnmurray]

introduce new API for finding the debug specific expression for a given source location (= hover location)

Please prioritize this aspect. Our debugger deals with a language where A and %A are two distinct variables. The existing behaviour displays the value of A when hovering over an occurrence of %A.

[GustavoASC]

We also need this because we are developing a COBOL debug extension. Since COBOL variables have hyphen as part of the name, this piece of code is probably making hover return only part of the variable name.

Providing an extension callback to configure hover behavior or allowing extension to specify a hover regex would be great.

Maybe I can help you, making a pull request to VSCode core, according to what you think is the best approach to develop this solution.

[weinand]

@GustavoASC thanks for the offer to submit a PR. But I'm already working on this new extension API.

[weinand]

I've created a new API request.

[weinand]

Work will continue in February.

[weinand]

Instead of introducing scope resolution API we've added new API for those cases where the scope resolution API would be used: an EvaluatableExpressionProvider for debug hovers and an InlineValuesProvider for the inline value feature.