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

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

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.

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!

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.

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

[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)'.

@elvizlai
See #29202 (comment)

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.

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

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

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"

@myitcv

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

See

• x/tools/gopls: improve handling for build tags #29202 (comment)
• net: DNS broken on darwin without cgo (1.13 regression) #31705

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

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.

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

@myitcv
Ah, sorry for confusing 🙏

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

• https://github.com/autozimu/LanguageClient-neovim/blob/6ee4c8994ee84609f8370aa4766b66c7cbad1424/src/language_server_protocol.rs#L1797-L1809

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.

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.

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.

@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