Skip to content

VM Service's lookupResolvedPackageUris returns different org-dartlang-sdk structure for Flutter apps from Dart #49863

@DanTup

Description

@DanTup

I'm not sure whether this is expected - if so, I think it needs documenting (it may already be, but I've not been able to find anything).

The DAP implementations use the VM Service's lookupResolvedPackageUris call to convert URIs like dart:code/uri.dart (which are provided in stack traces) to things that can be mapped to local file paths on the users machine (so that when debug stepping, the same files can be opened that the user gets if they use Go-to-Definition via the analyzer).

If I write code like this, and step into Uri.parse:

var a = Uri.parse('');

Then in the Dart SDK, lookupResolvedPackageUris converts this URI to org-dartlang-sdk:///sdk/lib/core/uri.dart

==> {
	"jsonrpc": "2.0",
	"id": "41",
	"method": "lookupResolvedPackageUris",
	"params": {
		"isolateId": "isolates/1481761977225271",
		"uris": [
			"dart:core/uri.dart"
		],
		"local": true
	}
}

<== {
	"jsonrpc": "2.0",
	"result": {
		"type": "UriList",
		"uris": [
			"org-dartlang-sdk:///sdk/lib/core/uri.dart"
		]
	},
	"id": "41"
}

Currently, the debug adapters assumed that org-dartlang-sdk:///sdk points to the root of the Dart SDK and correctly map this to the lib/code/uri.dart file in the Dart SDK (/sdk is one example given in the docs).

However, when running a Flutter app (using latest master) the result is org-dartlang-sdk:///third_party/dart/sdk/lib/core/uri.dart:

==> {
	"jsonrpc": "2.0",
	"id": "639",
	"method": "lookupResolvedPackageUris",
	"params": {
		"isolateId": "isolates/3750929181587719",
		"uris": [
			"dart:core/uri.dart"
		]
	}
}

<== {
	"jsonrpc": "2.0",
	"result": {
		"type": "UriList",
		"uris": [
			"org-dartlang-sdk:///third_party/dart/sdk/lib/core/uri.dart"
		]
	},
	"id": "639"
}

I could update the code to also assume org-dartlang-sdk:///third_party/dart/sdk should map to the root of the Dart SDK, however it makes me wonder whether there may be other differences that need to be accounted for. I don't know how the mapping for org-dartlang-sdk is built, but it would make sense to ensure any assumptions in the DAP match the actual rules (and include a note in the code where those rules can be found).

@bkonyi do you know if this is intended, and/or where the rules for org-dartlang-sdk are?

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-vmUse area-vm for VM related issues, including code coverage, and the AOT and JIT backends.legacy-area-front-endLegacy: Use area-dart-model instead.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions