Background:

An implementation of the DAP protocol for Dart needs to be able to get and set breakpoints and resolve stack traces specified in terms of true file system paths not custom Dart URI schemes such as google3:///, package: or org-dartlang-sdk:///.
The lookupPackageUris API in the VMService solves part but not all of this problem as google3:/// and org-dartlang-sdk:/// can be returned.

The lookupPackageUris provides file system uris on some platforms but returns google:/// uris for bazel builds.
This causes friction for IDEs as they need to guess the local file system path for google3:// URIs and need to know how to convert local file system paths to google3:/// uris.

There is a similar challenge for uris under the dart:sdk where the mapping is

Challenging cases for IDEs:
dart:io -> org-dartlang-sdk:///sdk/lib/io/io.dart
package:/foo/bar.dart -> google3:///dart/foo/lib/bar.dart
easy cases for IDEs:
package://foo/bar.dart -> /my/dir/packages/foo/bar.dart

Proposal

Have the embedder register service extensions that define how to resolve these uri schemes. This is similar to how the embedder registers apis to help with hot reload.

Define an api resolveLocalPaths that takes a list of uris that are google3:/// or org-dartlang-sdk:/// return true file system paths.

Define an api resolveDartUris that takes a list of uris and converts them to google3:/// or org-dartlang-sdk:/// if they are under the sdk directory or under the google3 project root.

These APIs should be implemented by flutter tool or the dart tool and not by the core VM Service as the VM lacks the knowledge to know how to resolve the custom google3:/// scheme and may not know what location for the SDK to use.

For google3:/// this api should be fairly easy to implement. As long as you know the root directory for the dart sdk, you know what to substitute for org-dartlang-sdk and as long as you know the google3 root directory you know what to substitute for google3:///. The one challenge is that if the file is not found under google3:/// we need to look in the generated files directory and know what the correct generated file directory is given the bazel config. Details of how to specify this robustly and keep it aligned with the analyzer are TBD.

What will be required that in google3, we will need to make sure flutter tools knows the root directory of the project and knows the directory of the dart sdk used. Potentially some of this information overlaps with the CFE that already knows how to convert from file system uris to Dart uris.

Open question: why isn't the Dart Analyzer the right tool to provide this resolution?
Answer: a DAP implementation for a language must not be coupled to the LSP implementation. We see issues in IntelliJ right now where breakpoints fail to be work due to the analyzer being in a broken state and we would like to avoid that and decouple questions about why debugging is working from questions about whether static analysis tooling is working.