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

Jump to bottom

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

Closed
oakad opened this issue Sep 20, 2020 · 3 comments
Closed

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
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.

Comments

@oakad
Copy link

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:
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
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Sep 20, 2020
@gopherbot gopherbot added this to the Unreleased milestone Sep 20, 2020
@stamblerre
Copy link
Contributor

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
@oakad
Copy link
Author

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
@stamblerre
Copy link
Contributor

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 removed this from the gopls/unplanned milestone Nov 13, 2020
@golang golang locked and limited conversation to collaborators Nov 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@oakad @stamblerre @gopherbot