Danny Tuppeny

I agree with most of the above.. I don't think this really affects package_config. I also think that ideally no tools should should be removing and re-adding these scheme prefixes....

> I'd rather allow package URIs with queries, like `package:foo/bar.dart?macro-generated` I don't personally have any opinion on these URIs, but for the URIs we'll use to communicate with the editor,...

For the URI that is used to communicate between LSP and the editor, and the editor and the debug adapter, we definitely cannot use `file:///`. It's not just that the...

> The obvious choices are the tools that macro-compilation is integrated into: Compilers and the analyzer. Maybe the LSP. I don't think the LSP server needs to know this directly...

> I don't thing we need to "resolve" a `dart-macro+package:foo/bar` to `dart-macro+file://home/me/dart/pkg/foo/lib/bar`. I'm not sure exactly what "resolve" means here. If you mean support in `package_config` or an `import`, then...

Do you mean that the VM Service would return the `dart-macro+file:///` URI in things like the stack trace? If yes, I think that would work but it feels odd to...

> As far as go to definition (and related features), I think it should by default go to the augmented declaration (the original one, without an augment keyword) I think...

Something I just remembered is that LSP has both a "definition" and a "declaration" request. We don't currently implement declaration, but perhaps we should implement it now (going to the...

> We had an in-office discussion yesterday and had come to the conclusion that "go to definition" should, at least for invocations, take the user to the last augmentation in...

> If the user chooses 'goto', can we control which one of the multiple options will be selected? I'd expect it to either be the first or the last, but...