Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

oakad opened this issue Sep 20, 2020 · 3 comments


Copy link

@oakad oakad commented Sep 20, 2020

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: 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

@gopherbot gopherbot added this to the Unreleased milestone Sep 20, 2020
Copy link

@stamblerre stamblerre commented Sep 21, 2020

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.

@stamblerre stamblerre removed this from the Unreleased milestone Sep 21, 2020
Copy link

@oakad oakad commented Sep 22, 2020

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 stamblerre added this to the gopls/unplanned milestone Oct 21, 2020
Copy link

@stamblerre stamblerre commented Nov 13, 2020

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.

@stamblerre stamblerre closed this Nov 13, 2020
@stamblerre stamblerre removed this from the gopls/unplanned milestone Nov 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants