Find references do not work because $GOPATH/src is a symbolic link

[kehu1991]

Hi,

I have a question about getting find references work with $GOPATH/src being a symbolic link.

The symbolic link was introduced so I don't need to change existing root project directory (which contains other language projects not just go). However, because of this, find references do not work with these two problems:

1. rootUri in init request is the resolved file uri. Because it doesn't string match $GOPATH/src, it's regarded as outside package.
2. filepath in find references request is also treated as outside package, so an error response gets returned.

My expected behavior is that go lang server will check if each $GOPATH/src is a symbolic link and if so, resolve it and use that as the actual path. Is there any gotcha that I missed with this approach?

I would love to contribute if someone can help confirm this is the right behavior!

Thanks, K

[keegancsmith]

Supporting this properly seems error prone. It seems like if your rootUri was inside of $GOPATH/src then this wouldn't be an issue. Could you not open up your editor at the $GOPATH path, instead of the symlinked destination.

[emidoots]

@keegancsmith I imagine this is a bigger issue once you consider that a monorepo is a GOPATH, so this means the langserver doesn't work very well in an editor environment when pointing it at a symlinked monorepo dir. I would say that is worth fixing / supporting generally if someone wants to open a PR for it with tests

[keegancsmith]

Do we have code somewhere that resolves symbolic links? Assuming your rootURI is in the GOPATH I don't see why this wouldn't work, even in the case you mention @slimsag.

[kehu1991]

Hi @keegancsmith, thank you for the quick reply! In case it caused confusion, let me clarify that $GOPATH/src is the symlink, which points to the actual project folder. To give a concrete example, here is some pseudo command output: [vm] echo $GOPATH /users/<user>/gopaths/gocode:/users/<user>/gopaths/godeps [vm] ls -sl /users/<user>/gopaths/gocode src -> /home/workspace bin ->/home/go-tools/bin # probably not relevant but bin is also a symlink pkg

And rootURI in init params is /home/workspace

If you resolve $GOPATH/src, then yes rootURI is in $GOPATH/src. However, what I observe is that go-langserver doesn't resolve and use string prefix to check if rootURI is inside $GOPATH/src, which will fail because $GOPATH/src (/users/<user>/gopaths/gocode/src) is not a prefix of rootURI (/home/workspace). https://github.com/sourcegraph/go-langserver/blob/1fe24b2b3fd1f420474fb872d944d2a1a93ddf63/langserver/build_context.go#L83

I tried open editor with $GOPATH/src, but editor will resolve this symlink to the actual path so rootURI will still be set as /home/workspace.

[jguenther]

@kehu1991 I tried but could never manage to get symlinks inside $GOPATH to behave correctly with go itself. I'd recommend moving the code to $GOPATH/src and make a symlink to there from your existing projects directory, rather than symlink $GOPATH/src to your existing projects directory. It doesn't cause any problems to have non-go projects in there.

Maybe not ideal, but it's been working great for me.