x/tools/gopls: support single file mode

[stamblerre]

When the user opens an individual file in their editor, we don't offer any language features. This is because we don't know the module root. Should we have some hack just to support this mode? We could run go env GOMOD and assume that is the root (if that is empty, the directory of the file could be the root).

Note that this will be particularly difficult, as we won't be able to initialize any views until we receive a textDocument/didOpen for the specific file.

[dpinela]

I sometimes write small one-off programs for simple jobs or to experiment, for which this would be very handy.

[pekim]

I think that the following relates to this issue, but apologies if it doesn't.

In my app (a work-in-progress Go editor) I would like to be able to initialise gopls without a workspace. Then add a workspace when a project window is opened. Add another workspace if another project is opened, and so on. And when a project window is closed, remove the workspace folder from the list of folders

Currently I cannot take this approach because if I send an initialize request with no workspace folder I run in to "single file mode not supported".

I intend on working around this for now by making a special case for the first project to open, and initialising gopls at that point with a single workspace. And if another project is opened, add a workspace with a workspace/workspaceFolders request that would include all open workspaces. However making a special case for the first project to open feels a little ugly.

A couple of questions around this.

1. Is my intended approach reasonable? I've not got as far as implementing it, as I've been working on getting a single workspace working in my editor first.
2. Will single file support allow me to initialize with no workspaces, and avoid the special case for the first workspace?

[pekim]

I've done some more reading, and I think that I was getting confused between multiple workspaces and multi-folder workspaces. If I understand correctly, a single language server (gopls) instance only supports a single workspace. And that workspace may support multiple folders. Although currently gopls only supports a workspace with at least one folder.

Launching multiple vscode instances and looking for gopls processes appears to confirm this.

So I'm going to keep it simple in my application, and launch a separate gopls instance for each of my open workspaces.

That means that support for single file mode probably won't be of interest to me.
Sorry for the noise that I've contributed to this issue.

(I think that #34111 looks like what I'm really after.)

[quasilyte]

What about this:

In the case of a single file mode, we expect a gopls user to send initializationOptions.singleFile that gives a path of a currently opened file.

We grab these options from here:

If we have an absolute path to a singleFile, we can then create a workspace folder in a same way we do it for params.RootURI:

if singleFile != "" {
	s.pendingFolders = []protocol.WorkspaceFolder{{
		URI:  "file://" + singleFile,
		Name: path.Base(singleFile),
	}}
}

For the VSCode, we would need to update initializationOptions used for a language server creation:

I tried it for myself and it seems to be working fine. There are some problems with locations that contain a lot of unrelated folders and files (like ~ or another generic directory), but it's a separate issue in my opinion, since opening the same folder in a normal way would result in the same problem.

If this plan seems right, I can send a CL that implements it. :)

[stamblerre]

Sorry for not replying earlier, @quasilyte. Thanks for thinking about this, but I'm hoping that we can avoid having an extra setting for this mode. We will be doing work on managing multiple module roots for gopls/v0.5.0, so I'm hoping we can handle this as part of that work.

Also commenting here as a reminder: We should remember to try to handle the case described in #37875 (comment).