Add an optional `source` and `line`+`column` range for a `Variable`

[gfszr]

A Scope structures contain optional fields describing the source range in which the scope lies in - this is useful for presenting various per-frame/per-scope information overlaying over source code. This request proposes the same for Variable stuctures as well to describe the location where the variable is defined:

{
  /**
   * The source for this variable's definition. 
   */
  source?: Source;

  /**
   * The start line of the range where the variable is defined. 
   */
  line?: number;

  /**
   * Start position of the range where the variable is defined. It is measured in UTF-16
   * code units and the client capability `columnsStartAt1` determines whether
   * it is 0- or 1-based.
   */
  column?: number;

  /**
   * The end line of the range where this variable is defined. 
   */
  endLine?: number;

  /**
   * End position of the range where this variable is defined. It is measured in UTF-16
   * code units and the client capability `columnsStartAt1` determines whether
   * it is 0- or 1-based.
   */
  endColumn?: number
}

Using the above optional information for a variable, a UI can, for instance, overlay its value next to its definition, similar to IntelliJ IDEs' Inline Debugger feature:

[roblourens]

And similar to vscode's "inline values" feature 😁

Is the point of this request to enable that feature? Or improve it?

[gfszr]

Both improving it (Right now, it isn't as good as IntelliJ's one), and allowing usage on editors which do not have strong language-parsing features (Which is the main reason for this request). As this might be either very easy / harder by a debugger to fill this information, it is marked optional.

[weinand]

A debugger typically has no access to an AST (or related symbol information) and therefore doesn't know the source range of a variable declaration. So adding "line+column" information to DAP does not make a lot of sense if most debug extensions could not provide that information. For that reason we have decided not to include detailed source range information in DAP (only exception are scope ranges).

Instead VS Code offers debug related extension API ("providers") for inline values (as shown above in your screenshot) and debug hovers which can be implemented by language extensions. Typical language extensions have access to the AST and can easily determine the source range of language constructs.

[mickaelistria]

A debugger typically has no access to an AST (or related symbol information) and therefore doesn't know the source range of a variable declaration. So adding "line+column" information to DAP does not make a lot of sense if most debug extensions could not provide that information. For that reason we have decided not to include detailed source range information in DAP (only exception are scope ranges).

OK.

Typical language extensions have access to the AST and can easily determine the source range of language constructs.

That is less and less true nowadays with more and more tools being built on a combination of a Language Server and a Debug Adapter. The AST is not accessible to the IDE, nor to the Debug Adapter.
Do I get it right that ideally, the LSP should provide some evaluatableRange: Position -> Range function to allow resolving a position (provided by the IDE eg when hovering or for inlay hints), and that could then be passed to the Debug Adapter?

[weinand]

@mickaelistria yes, LSP should provide some "evaluatableRange: Position -> Range" function.

But I'm not sure that there is a need to pass that information to the Debug Adapter. I think it is more an extension API (of the client) that could use the info from the LSP and combine it with some DAP functionality.

E.g. VS Code uses that approach for the debug hover and for debug inline values: an extension API hook exists that can be implemented by using an LSP, and the DAP evaluate request is used to retrieve the value.
(Since VS Code knows nothing about LSP, LSP cannot be used generically. This is different from DAP which is known by VS Code)

---

You said:

... more and more tools being built on a combination of a Language Server and a Debug Adapter.

I'm aware of the Java extension which combines LSP and DA. What other languages are using this approach?

[mickaelistria]

I'm aware of the Java extension which combines LSP and DA. What other languages are using this approach?

In Eclipse IDE land, we have LSP+DAP enabled for JavaScript, TypeScript, HTML, C# at least. But the issue may also surface without DAP and using other debuggers (hence I agree LSP is the right place to get the expression to evaluate)

[mickaelistria]

@weinand I opened microsoft/language-server-protocol#1596 , your feedback on that proposal would be welcome.