x/tools/gopls: Bazel Build linked directories in a workspace root break gopls in a curious way

[oakad]

Clearly related to #39841 and it does feels like a regression.

I believe, it was not an issue in earlier versions of gopls, but it is definitely very pronounced with 0.5.0

Platform info:
golang.org/x/tools/gopls v0.5.0
go version go1.14.6 linux/amd64
vscode 1.49.1

Bazel Build, as part of the build process (not related to Go proper), creates several helper directories and links them into the workspace. In particular, it will create a link called "bazel-" pointing to a directory (so called "execroot") full of soft links to all the files in the workspace.

Under some circumstances, it is desirable to build Bazel artifacts in the same directory as some Go module. However, it seems, that presence of those Bazel "link farms" confuses gopls substantially, causes it to report various "phantom" code issues and crash every now and then.

In the logs, the indication of the coming problem can be observed:

query=[file=<some project>/<some path>/<some file>.go] - everything works nicely

query=[file=<some project>/bazel-<some project>/<some path>/<some file>.go] - suddenly, a trouble is ahead

It is not clear, why gopls suddenly decides to prefer the link farm as compared to the actual file.

No crash dump is present in the logs, apart from Connection to server got closed. Server will restart

[stamblerre]

gopls does not currently have full support for Bazel (#37205), so anything that works is likely due to luck. To investigate further, I will need a complete gopls log--you can find out how to capture the logs with higher verbosity here.

[oakad]

It need not support bazel, but it also should not break when encountering a link farm - those are created by other tools as well (or even particularly cunning makefiles).

I will look into capturing a verbose log at come convenient opportunity.

[stamblerre]

We've made some improvements for symlink support, but without a log, there's not much else to investigate. Closing this as a duplicate of #37205.

@oakad: Please open a new issue if you encounter this problem again.