Associate a virtual VSCode editor with a local Swift package

[elongl]

I have a use-case in which I create virtual VSCode editors. That mostly means that they don't have a regular .fsPath on their vscode.Uri and that they're scheme is not file://. I want to be able to do Jump to Definition of types that appear in my virtual editor to types that are defined as Swift files on my local machine, say /path/to/swift/package.

In order to do that, I've thought of a couple of ways.

1. Associate the virtual editor with the package so that the vscode-swift thinks it's part of that package and resolves types accordingly.
2. Expand the search paths to also search my package, like how the SDK types (Swift.Decoder) types are resolved even though they're outside of the package.

What's the simplest way to solve this? Thanks.

[plemarquand]

This is an interesting question; its going to involve teaching sourcekit-lsp about the contents of the virtual editor since that is what powers symbol resolution. The extension, and sourcekit-lsp, already work with these virtual files when doing macro expansions. These virtual documents have the scheme sourcekit-lsp:, and it may be as simple as using this scheme for your virtual files. @ahoppen and @lokesh-tr both have experience in this area, interested in your thoughts here.

[elongl]

Hi @plemarquand, thanks for the help.
I ended up doing this (sorry for the PR, accidental), but it only solved part of the problem.

I'm still troubling to figure out how can I add/resolve types that are outside of the VSCode's workspace folder.
I've attempted to change the code so that workspaceFolder is not required in the WorkspaceContext and instead the flow of focusUri would search for packages from that vscode.Uri and its parent folders, even if it's not within a VSCode workspace, but that didn't end up working so well. If you have any tips on that regard it'd be great.

[ahoppen]

From SourceKit-LSP’s perspective, the problem is that it needs to get compiler arguments that would be used to build the file so it can provide semantic functionality. The basic information here would include which target the source file is part of but there’s a whole rabbit tail of other options (-D flags, SDK search path, search path of transitive dependencies, …).

The best option I could suggest to get functionality within the files, is that there could be a special URL scheme to open the virtual file and pass a file on disk that should be used to get the compiler arguments – ie. you essentially tell SourceKit-LSP to treat the virtual file as being equivalent to that file within the package. Would that seem feasible to you?

Now, with this, you still wouldn’t be able to navigate from files on disk to the virtual file because the files on disk don’t know anything about the virtual file. We also wouldn’t be able to run background indexing for the virtual file because that highly relies on files on disk. Because of this, functionality that needs a global understanding of your project like find call hierarchy won’t be able to show entries from your virtual file. This would be similar to the behavior that you get if you open standalone Swift files (without a package) at the moment. Not sure what your application is, and if those trade-offs are acceptable.

Also: What exactly are you trying to accomplish with the virtual files? That might make it easier to understand your use case.

[elongl]

Actually, if I understand correctly, that's exactly what I ended up doing. I expanded the uriConverters to handle my own virtual file URIs and return the paths on the file system.

Now my main problem is that the extension still requires me to open the VSCode folder on where the Swift package is located which I'd want to avoid. For example, I have /tmp/codebase/<MANY_SWIFT_FILES>, I want the user to be able to arbitrarily open whichever VSCode folder that he wants, but after fixing the URIs using the uriConverters, the extension would still have the context of which package I'm working on.

How can I do that?

---

In terms of what I'm doing, basically I've implemented my own vscode.FileSystemProvider that handles serving Swift files over the network. I cannot elaborate too much on the product use-case unfortunately 🙏🏽

Thanks a lot.

[elongl]

Another weird problem, after a few seconds where the extension does work.
It suddenly stops working and I'm constantly getting this error saying "Failed to find snapshot for file://...". What might cause this?

[ahoppen]

Actually, if I understand correctly, that's exactly what I ended up doing. I expanded the uriConverters to handle my own virtual file URIs and return the paths on the file system.

Could you show an example of how your URIs look like? That might also help understand the Failed to find snapshot problem.

Now my main problem is that the extension still requires me to open the VSCode folder on where the Swift package is located which I'd want to avoid.

While it might be possible to avoid requiring the user to open the package first by expanding the logic in SourceKit-LSP’s findImplicitWorkspace, SourceKit-LSP will still need to load the package manifest to get the build settings for the file on disk that is used for build settings, so you would just be hiding that work from the user but it would still be happening. I don’t know how elaborate your setup is and how much control you have over the build system but you might consider implementing a custom BSP server that can provide the build settings.

[elongl]

Yeah, of course here's an example of some of the errors I'm getting:

[Error - 7:08:12 PM] Request textDocument/definition failed.
Message: Failed to find snapshot for 'file:///Users/egk/.this/is/an/example.swift'
  Code: -32001

This problem is currently more pressing. It just works perfectly and then stops working after a few seconds. Not sure why I'm getting the "Failed to find snapshot ..."

---

While it might be possible to avoid requiring the user to open the package first by expanding the logic in SourceKit-LSP’s findImplicitWorkspace, SourceKit-LSP will still need to load the package manifest to get the build settings for the file on disk that is used for build settings, so you would just be hiding that work from the user but it would still be happening. I don’t know how elaborate your setup is and how much control you have over the build system but you might consider implementing a custom BSP server that can provide the build settings.

Yeah, I'm completely fine with the logic staying as-is, I just don't want the VSCode workspace to be a requirement.
Are there any ways of doing that while only changing the vscode-swift and not the sourcekit-lsp? Up until now I didn't need to touch it and I'm trying to keep it that way. Basically I want to fabricate the workspace.

---

By the way, Is there some way of having a more direct communication? Like Discord or X? Totally understand if not.

[ahoppen]

This problem is currently more pressing. It just works perfectly and then stops working after a few seconds. Not sure why I'm getting the "Failed to find snapshot …"

Did you send a textDocument/didOpen request for this document?

Yeah, I'm completely fine with the logic staying as-is, I just don't want the VSCode workspace to be a requirement.
Are there any ways of doing that while only changing the vscode-swift and not the sourcekit-lsp? Up until now I didn't need to touch it and I'm trying to keep it that way. Basically I want to fabricate the workspace.

Since I don’t fully understand what kind of URIs you are using, this is hard to answer. Either things will work or they won’t, in which case changes to SourceKit-LSP will be necessary. Are you passing file:// URIs to SourceKit-LSP? If so, do these files exist on the local file system?

By the way, Is there some way of having a more direct communication? Like Discord or X? Totally understand if not.

I think this is the best form of communication at the moment.

[lokesh-tr]

I don't really have anything to add to what @ahoppen said, he summed it up well. The custom url scheme for the virtual documents were designed to be very flexible. Even for macro expansions, we use the files on disk to derive the compiler arguments, which then allowed us to get semantic functionality in the virtual documents. Virtual documents are not the same as Files on Disk so expect some trade-offs to be made. And, I'm curious about your use case as well.

[elongl]

Considering that I use uriConverters so that they point to regular files on disk. Are there any tradeoffs/problems or should I expect things to work normally?