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

Open
oakad opened this issue Sep 20, 2020 · 2 comments
Labels

Comments

@oakad
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:
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 this to the Unreleased milestone Sep 20, 2020
@stamblerre
Copy link
Contributor

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

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.