Variable Substitution in launch.json not visible in debug configuration provider

[mike-lischke]

Issue Type: Bug

According to this paragraph variable substitution is supposed to work also in launch.json, used to configure debug sessions. However it appears not to work, at least I don't get the resolved variables in my DebugConfigurationProvider.resolveDebugConfiguration function. The passed in options still contain the unresolved variables, making it so impossible to use the given values (e.g. the current file, given as ${file} to set up my debugger.

Here's a sshot that shows the extension host with the launch setting and the debug config resolver:

VS Code version: Code 1.40.1 (8795a98, 2019-11-13T16:47:44.719Z)
OS version: Darwin x64 19.0.0

System Info

Item	Value
CPUs	Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz (12 x 3500)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off surface_control: disabled_off surface_synchronization: enabled_on video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off webgl: enabled webgl2: enabled
Load (avg)	2, 2, 2
Memory (System)	32.00GB (9.08GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (21)

Extension	Author (truncated)	Version
dot	Ste	0.0.1
numbered-bookmarks	ale	6.2.1
spellright	ban	3.0.48
vscode-svgviewer	css	2.0.0
vscode-eslint	dba	1.9.1
xml	Dot	2.5.0
vscode-wasm	dts	1.2.1
gitlens	eam	10.2.0
tslint	eg2	1.0.44
php-intellisense	fel	2.3.13
vscode-mysql	for	0.4.0
duk-debug	Har	0.5.6
live-html-previewer	hdg	0.3.0
vscode-auto-open-markdown-preview	hnw	0.0.4
beautify	Hoo	1.5.0
svg	joc	1.0.5
vscode-phpfmt	kok	1.0.30
vscode-antlr4	mik	2.2.3
prettify-json	moh	0.0.3
debugger-for-chrome	msj	4.12.1
vscode-yacc	se2	1.1.0

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Enables dependant variable substitution (#80220)

[weinand]

By design variable substitution occurs after DebugConfigurationProvider.resolveDebugConfiguration and before passing the launch config to the debug adapter.
This makes it possible to have DebugConfigurationProvider.resolveDebugConfiguration add additional variables.

[mike-lischke]

But how can I then determine the actual values for the variables if not in that method, which is supposed to resolve the configuration?

[weinand]

All resolved values are available in your debug adapter which is part of your extension.

[mike-lischke]

Hmm, sorry, that makes not much sense given the description of the resolve function:

Resolves a debug configuration by filling in missing values or by adding/changing/removing attributes.

How can I change attributes, if I cannot understand them? Seems there is a discrepancy between the purpose you intent and what can be understood from the description.

That bears a side question: if the resolve function is not intented to validate configuration values (and cancel the debug session if something is wrong), what else should we use instead for that kind of processing?

[weinand]

The description of resolveDebugConfiguration makes a lot of sense since "filling in missing" values and "adding/changing/removing attributes" can be done without a need to see the "final" values.

Evidence for this you can see in node-debug's resolve method.

Any validation that can only be performed on the final values can be done (and is actually done) in the debug adapter (see launchRequest in the node-debug DA).

Having said this, I can still imagine to introduce a new aboutToLaunch method on the DebugConfigurationProvider that receives the "final" fully resolved debug configuration.

I've changed this issue into a feature request and I'm now waiting for upvotes...

[mike-lischke]

I see your points, however launching the debug adapter might involve quite a few things to do, which are unnecessary when there are problems with the files being debugged. Hence my original idea was to figure out everything in the resolve function upfront, before I even create the debug adapter. I'll move my validation logic to launchRequest then. Thanks for the hint.

A new validation function might still be useful (be it named aboutToLaunch or validate or whatever).