Extension API for Inline Values

[weinand]

Today the "Show Inline Values" feature of VS Code's debugger is based on a generic implementation in the VS Code core and provides neither customisability through settings, nor extensibility via extensions.

As a consequence, it is not a perfect fit for all languages (e.g. #101797) and sometimes even shows incorrect values because it doesn't understand the scope regions of the underlying language.

This features asks for an extension API that either replaces the built-in implementation completely or allows to replace parts of the implementation with custom code.

[weinand]

The current generic implementation works as follows:

• in a debug session VS Code considers only the source of the focused stack frame for showing inline values.
• VS Code's internal tokenizer is used to find all variables in the source (without understanding scope regions of the language).
• the potential variables are looked up in the VARIABLE views and for successful matches the value is shown inline in the editor.

This implementation is lightweight and scales well because:

• instead of a full language parser or AST the implementation piggybacks on the results of the tokenizer.
• finding the variable values piggybacks on the already fetched variable values available in the VARIABLE view.
• any false positives of the tokenizer are easily eliminated because there will be no matching variables in the VARIABLES view.

Problems:

• same named variables from different scope ranges show all the same value.
• some lookups don't really work or make no sense (see Debugger: debug.inlineValues support for case insensitive variable names  #101797, Strange behavior of inline values #113813, "Inline Values" shows source of functions  #113987)
• formatting of the inlined value presentation is hardcoded to variable = value.

[weinand]

A first attempt for designing an extension API for inline values tried to use a similar approach as done for the debug hover with the EvaluatableExpressionProvider. In the debug hover case the provider returns an expression for a source location typically determined by the mouse, and then this expression is evaluated by the debug adapter and the result is presented in a hover window.

For the "inline values" feature we tried to reuse the EvaluatableExpressionProvider by introducing a second method that takes a source line number as input and returns an array of {name, expressions} pairs. VS Code would evaluate the expression by the debug adapter and the present the name with the value in the editor at the end of the line.

A prototype based on this approach showed two problem areas:

• sending multiple "evaluate" requests for every source line to the debug adapter can be slow and affects the stepping performance significantly.
• Since the language tokenizer is not available in extensions, implementing an EvaluatableExpressionProvider from scratch is difficult. The only realistic way to get this done is by making the EvaluatableExpressionProvider a companion to a language server so that it has access to the parser or AST.