Provide a way in the VM Service to resolve package: URIs to file paths

[DanTup]

This has come up a few times and in VS Code I've somewhat worked around it by making assumptions about the package_config.json file being used (that is, assuming the never overrides it and it's always in the "obvious" location for a given script).

For the DAP implementation in the SDK it seems less reasonable to potentially get this wrong so it would be better to have a supported way to resolve a package: URI. Without this, whenever DAP hits a breakpoint/exception and gets a call stack, it is unable to resolve the package: URIs to a file paths to provide to the editor, which means the editor is unable to show the user the code where the debugger is paused (or step through it). In theory we could download the source from the VM, but that's a confusing experience for the user because they have two copies of the same file, and the editor maintains breakpoints within them separately.

There might be a few ways to support this:

• An API that can resolve a URI (or a set of URIs)
• An API that returns the whole lookup table and allows the client (or in DAP's case, the debug adapter) to then perform the mapping

The first may involve more round trips, though may work better if the mapping is potentially huge (or can change, or if the mapping may differ per-isolate - something I couldn't find an obvious answer to).

@bkonyi @devoncarew

[mraleph]

Tentatively marking area-vm. Maybe we should have an area-dds?

[devoncarew]

Maybe we should have an area-dds?

Note that this request (not explicitly stated above) is for a 1st class API in the vm service protocol, not a potentially optional one in DDS.

An API that returns the whole lookup table and allows the client (or in DAP's case, the debug adapter) to then perform the mapping

Adding @jwren, who may be familiar with how resolution works internally. We don't use .packages files and instead resolve against the entire codebase. I assume that doing something like returning a complete mapping wouldn't be feasible but would like to confirm.

[jacob314]

This is very similar to:
#45530

For g3, the mapping would be quite large as there are a lot of libraries so I would recommend just an API to convert paths rather than surfacing a table of all mappings.
The one thing to add from the other bug is it would be helpful to perform mappings in BOTH directions in DDS.
We need to be able to go from a file path to the correct package: uri and need to go from a package: back to a file path.

[DanTup]

Ah yeah, we could probably close this in favour of that. Devon suggested it should be core VM service rather than DDS above (I'm also unsure if DDS could do it without info directly from the VM), but which supplies the data is less important to me.

I don't know if it changes the priority, but this is somewhat blocking for DAP now as we can't step into files for any package: URI.

I would recommend just an API to convert paths rather than surfacing a table of all mappings

In that case, it may be good to be able to batch them (or at least confirmation that sending many of them concurrently is fine), as in something like a stackTraceRequest we'll potentially need to map many of them all at once.

[jacob314]

Batch SGTM. I'm fine with either in the VM service or DDS. For g3, my expectation is we will need to customize a bit so DDS might be an easier place to do the customizing and DDS would enable implementing the logic once in Dart. In general I don't think we need to support setting breakpoints from IDEs for pure VM service clients only DDS.

[DanTup]

In general I don't think we need to support setting breakpoints from IDEs for pure VM service clients only DDS.

This isn't only for setting breakpoints, it's also required anytime the debugger pauses (for example on an exception or if the user calls debugger()).

Right now for DAP there's a flag to disable DDS. If we implemented this in DDS, we might need to (or at least want to consider) removing that flag, since debugging wouldn't work correctly without DDS then (and we might not be able to easily convey that to the user, so it could just look buggy).

[a-siva]

Why does DAP disable DDS ?

[DanTup]

@a-siva it doesn't disable it by default, but there is a flag that can be used to disable it. I'm not sure if that flag is necessary though (and if this is implemented in DDS I think it certainly should be removed).

@devoncarew expressed a preference for this being a core VM service rather than in DDS above though - I'm not familiar enough with this to know the pros/cons of doing it either way.

[devoncarew]

expressed a preference for this being a core VM service rather than in DDS above though - I'm not familiar enough with this to know the pros/cons of doing it either way

Yes, I suspect that the info that would be used to implement this call is already known by the VM / vm service, and that the functionality would be broadly useful to clients (to know which urls to create when setting breakpoints, or, to know which source files to display when paused at a location - the inverse mapping). I see DDS being a better fit for functionality that we don't always care is there (for when we have the vm service but not DDS) or for functionality with more sophistication than we want to put in the VM service (client middleware).

[bkonyi]

Yeah, this should probably live in the VM service protocol as the VM has access to the URI mappings anyway.

As for what the API should look like, we should be fine providing an RPC that resolves a single URI per request. I don't believe we have any other RPCs that offer batch functionality and the performance overhead of sending multiple requests vs batching was determined to be quite small last time we looked into offering batch RPCs.

[DanTup]

I remembered there some additional logic in VS Code to handle org-dartlang-app URIs. I presume they could also be handled over this API (if I understand correctly, the web proxy would provide its implementation for this method, and it could handle those in there)?