DebugConfigurationProvider should support compound targets

[karljs]

Because compound targets are not debug "configurations", but rather included separately under the "compounds" key in launch.json, it is not possible for a debugging extension to provide a compound configuration. It should be possible, in some way, to dynamically provide a compound target.

There is an overlapping request from 3.5 years ago which was marked "out of scope" with no explanation:
#37193

I am hoping that this can be re-evaluated now.

[vscodebot]

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

• Input variables only work with one configuration in a compound launch config (#66801)

[alexweininger]

A way to dynamically resolve compound configurations based on the current debug configurations would be much appreciated. I would love to see resolveCompoundConfiguration and provideCompoundConfigurations.

[weinand]

For DebugConfigurationProvider.provideCompoundConfiguration we could just extend the return type to allow for compound configurations, e.g. something like (DebugConfiguration | DebugCompoundConfiguration)[]. I think that would be non-breaking.

Doing the same for DebugConfigurationProvider.resolveDebugConfiguration is not possible because multiple DebugConfigurationProvider registered for the same debug type result in chained resolveDebugConfiguration calls so that the returned result from one is passed as an argument into the next.
Consequently we would have to change the signature of resolveDebugConfiguration in two locations:

resolveDebugConfiguration?(..., debugConfiguration: DebugConfiguration | DebugCompoundConfiguration, ...): 
       ProviderResult<DebugConfiguration | DebugCompoundConfiguration>;

but this would be a breaking change.

Introducing a new resolveDebugConfigurations method (note the plural 's') would result in some ugly and complex semantics: when is it called and how does it interact with resolveDebugConfiguration (singular) if both are implemented. I really don't like this.

But maybe there is a workaround: if it is really necessary to start more than one debug session from resolveDebugConfigurations, the additional sessions could be started with the debug.startDebugging API.

[alexweininger]

For DebugConfigurationProvider.provideCompoundConfiguration we could just extend the return type to allow for compound configurations, e.g. something like (DebugConfiguration | DebugCompoundConfiguration)[]. I think that would be non-breaking.

This solution sounds like it would work perfectly.

But maybe there is a workaround: if it is really necessary to start more than one debug session from resolveDebugConfigurations, the additional sessions could be started with the debug.startDebugging API.

I will try out this workaround soon and report back.

Thanks!

cc: @nturinski

[alexweininger]

But maybe there is a workaround: if it is really necessary to start more than one debug session from resolveDebugConfigurations, the additional sessions could be started with the debug.startDebugging API.

So far in my prototyping the suggested workaround has worked well. I think we will go forward using this solution.

cc: @isidorn

[isidorn]

@alexweininger this is great to now. And I agree going forward with that approach sounds good.

Maybe it would be useful that we schedule a 30min sync meeting where we would just talk about debugging.
We would be interested in how Azure extensions are using the debug infrastructure.
Let me know what you think and keep in mind that next week I am on vacation so I might be slow to respond.