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/cmd/gopls: errors reported in package with no errors #32247

Closed
myitcv opened this issue May 25, 2019 · 21 comments
Closed

x/tools/cmd/gopls: errors reported in package with no errors #32247

myitcv opened this issue May 25, 2019 · 21 comments

Comments

@myitcv
Copy link
Member

@myitcv myitcv commented May 25, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12.5 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20190524210228-3d17549cdc6b

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOBIN="/home/myitcv/gostuff/src/github.com/myitcv/govim/cmd/govim/.bin"
GOCACHE="/home/myitcv/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPROXY="https://proxy.golang.org/"
GORACE=""
GOROOT="/home/myitcv/gos"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build230798786=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Opened a file in Vim (using govim) that is part of a package that compiles and on which tests pass; received the following error message:

failed to run analyses for file:///home/myitcv/gostuff/src/github.com/myitcv/govim/cmd/govim/main.go: analysis skipped due to errors in package: [/home/myitcv/gos/src/net/lookup_unix.go:324:23: undeclared name: cgoLookupPTR /home/myitcv/gos/src/net/lookup_unix.go:124:24: undeclared name: cgoLooku
pCNAME /home/myitcv/gos/src/net/lookup_unix.go:108:23: undeclared name: cgoLookupPort /home/myitcv/gos/src/net/lookup_unix.go:96:24: undeclared name: cgoLookupIP /home/myitcv/gos/src/net/lookup_unix.go:81:24: undeclared name: cgoLookupHost]

This appears to have been introduced as part of https://go-review.googlesource.com/c/tools/+/178681

What did you expect to see?

No error message.

What did you see instead?

The above error message.


cc @stamblerre @ianthehat

@gopherbot gopherbot added this to the Unreleased milestone May 25, 2019
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 25, 2019

Is this error message logged or shown as a diagnostic? That CL changed it so that it would not show that diagnostic message anymore.

@myitcv
Copy link
Member Author

@myitcv myitcv commented May 25, 2019

Sorry, I forgot to include that critical detail: it's logged.

@myitcv
Copy link
Member Author

@myitcv myitcv commented May 25, 2019

It comes through as an error message though; so my expectation was the user should know about it. i.e. there has been an error, something has gone wrong.

@jan-xyz
Copy link

@jan-xyz jan-xyz commented May 26, 2019

I encounter the same error. It occurs when I freshly start vim. If I leave the file/buffer open for a while it starts working after a minute or so. I haven't found the right timing yet. I just opened the buffer switched to this tab to describe the problem, went back to verify the error and the error was gone. I tried that a few times and it seemed to solve the error. Could it be that the server needs a while to start?

I found this recent change which you labeled as "fixing a race condition" and it is concerned with package scanning. If I install gopls before that commit, the error is gone.

golang/tools@d532c07

My setup is neovim with languageClient-neovim and gopls. If I can help in any way hit me up!

@myitcv
Copy link
Member Author

@myitcv myitcv commented May 26, 2019

I think the other point to note, at least in my case, is that there should not be any type checking errors. The package in question compiles without error.

@mathieupost
Copy link

@mathieupost mathieupost commented May 27, 2019

Exact same issue here with latest version from master. Package compiles, but I'm getting the same error message from gopls.

@elvizlai
Copy link

@elvizlai elvizlai commented May 28, 2019

[Error - 上午9:17:45] failed to run analyses for file:///Users/elvizlai/xxxx/main.go: analysis skipped due to errors in package: [/usr/local/Cellar/go/1.12.5/libexec/src/net/lookup_unix.go:324:23: undeclared name: cgoLookupPTR /usr/local/Cellar/go/1.12.5/libexec/src/net/lookup_unix.go:124:24: undeclared name: cgoLookupCNAME /usr/local/Cellar/go/1.12.5/libexec/src/net/lookup_unix.go:108:23: undeclared name: cgoLookupPort /usr/local/Cellar/go/1.12.5/libexec/src/net/lookup_unix.go:96:24: undeclared name: cgoLookupIP /usr/local/Cellar/go/1.12.5/libexec/src/net/lookup_unix.go:81:24: undeclared name: cgoLookupHost]
[Trace - 9:17:54 AM] Sending request 'textDocument/hover - (4)'.

@zchee
Copy link
Contributor

@zchee zchee commented May 28, 2019

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 28, 2019

I believe that these errors are related to build tags / CGO, which is why the package compiles but still has errors. They didn't appear before because of a race condition. However, these errors are being logged, rather than published as diagnostics, so I'm wondering why they are being shown to the user? I would not expect these to be user facing errors.

@gopherbot
Copy link

@gopherbot gopherbot commented May 28, 2019

Change https://golang.org/cl/179218 mentions this issue: internal/lsp: run analyses despite some errors

@zchee
Copy link
Contributor

@zchee zchee commented May 28, 2019

@stamblerre

I believe that these errors are related to build tags / CGO

I think so too, occur only on darwin.

However, these errors are being logged, rather than published as diagnostics, so I'm wondering why they are being shown to the user?

At least the autozimu/LanguageClient-neovim will display internal error if server side has error. This implements different to show diagnostic. Therefore user shown(maybe)
Note that I don't know vscode behavior.

@myitcv
Copy link
Member Author

@myitcv myitcv commented May 28, 2019

I believe that these errors are related to build tags / CGO, which is why the package compiles but still has errors

Is this being tracked somewhere? Because there should be no errors, at least in the instance I reported here.

However, these errors are being logged, rather than published as diagnostics, so I'm wondering why they are being shown to the user?

If an error is reported by gopls, what is the expectation on the client?

An error of this sort suggests to me (although I'm hoping the spec is more prescriptive) "there was a problem with the language server, you should know about this"

@zchee
Copy link
Contributor

@zchee zchee commented May 28, 2019

@myitcv

Is this being tracked somewhere? Because there should be no errors, at least in the instance I reported here.

See

@myitcv
Copy link
Member Author

@myitcv myitcv commented May 28, 2019

There appears to be a lot of Mac discussion there; I'm on Linux. Is this the same issue?

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 28, 2019

So there is a window/logMessage call and a window/showMessage call. In this case, we are just logging a message, so I would not expect it to be shown to the user. We actually log errors a lot in gopls, in cases where we would want to see this information in logs, but it's not necessary for the user.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 28, 2019

Yes, it should be the same error. Any code that depends on packages with build tags will probably cause this error.

gopherbot pushed a commit to golang/tools that referenced this issue May 28, 2019
Updates golang/go#32247

Change-Id: Id474e62ea70676c782eb49dddebd64d7f274d2cf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/179218
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
@zchee
Copy link
Contributor

@zchee zchee commented May 28, 2019

@myitcv
Ah, sorry for confusing 🙏

@zchee
Copy link
Contributor

@zchee zchee commented May 28, 2019

@stamblerre
FYI, autozimu/LanguageClient-neovim is incorrect(see below) implemented window/logMessage.

self.vim()?.echomsg(&msg) will be shown any error msg to vim users with echo area. therefore vim users confusing.
This API might be interpreted differently depending on the editors behavior.

In vim behavior, vim can see echo area log. It's not wrote I/O. just on-memory.
If use echo command, not stock any msg to echo log. If use echomsg, vim will stock any msg to echo log. (maybe @myitcv already know)
So, That behavior might be correct on vim. It is both logMessage and showMessage on vim.


Sorry noisy.

@zikaeroh
Copy link
Contributor

@zikaeroh zikaeroh commented May 28, 2019

That most recent commit also fixed an issue I was about to report; I have an export_test.go file I use to export things to other packages for testing (similarly to what's done in the Go tests themselves).

Before that commit, files which used functions exported from export_test.go would show those uses as errors, but now work correctly. This scenario used to work a few weeks ago but broke fairly recently (and is now back to working). Things exported in _test.go files might be something to test in addition to build tag differences.

@zikaeroh
Copy link
Contributor

@zikaeroh zikaeroh commented May 29, 2019

Hmm, after doing more work the issue came back. Maybe it wasn't fixed and that commit wasn't related after all; I'll try to put together a repro and file a new issue.

@myitcv
Copy link
Member Author

@myitcv myitcv commented May 29, 2019

@stamblerre

So there is a window/logMessage call and a window/showMessage call

Perfect, thank you, that's exactly the distinction I was looking/hoping for.

@zchee - I think the LogMessage client method is, as @stamblerre kindly pointed out, just that, for logging a message, with a given level of severity. In govim I am simply going to have that message be added to the govim log. From Vim, the user can ask "where is the govim log?" but I'm not actively going to surface any govim/gopls log messages.

However the ShowMessage method will require some thought (for now gopls does not call this method). In this first instance I think it would be acceptable to echom the message, with a highlight colour appropriate for the severity, for example for an error:

echohl ErrorMsg | echom "message here" | echohl None
@myitcv myitcv closed this May 29, 2019
@golang golang locked and limited conversation to collaborators May 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

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