x/tools/gopls: bad go.mod affects anayses but not formatting; no errors in logs

[ainar-g]

What did you do?

I'm using Neovim nightly (0.5.0+ubuntu2+git202102080233-02a3c4179) with the official nvim-lspconfig package installed (041dfd7f). My configuration:

lspconfig = require "lspconfig"
lspconfig.gopls.setup {
  cmd = {"gopls", "serve"},
  log_level = vim.lsp.protocol.MessageType.Log,
  message_level = vim.lsp.protocol.MessageType.Log,
  settings = {
    gopls = {
      analyses = {
        fieldalignment = true,
        -- …
      },
      ["build.experimentalWorkspaceModule"] = true,
      ["formatting.gofumpt"] = true,
      ["staticcheck"] = true,
      ["ui.verboseOutput"] = true,
    },
  },
}

In one of my personal projects I've had a bad go.mod:

package example.com/mod

Notice the keyword package instead of module.

What did you expect to see?

Error messages in the logs.

What did you see instead?

No error messages. Formatting works, but not analyses like fieldalignment.

Build info

golang.org/x/tools/gopls master
    golang.org/x/tools/gopls@v0.0.0-20210210013322-d4590503678b h1:ln+MiJnzcfN8CAjS49XevFBaRh/Pv0b21htr04EB9WY=
    github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/google/go-cmp@v0.5.4 h1:L8R9j+yAqZuZjsqh/z+F1NCffTKKLShY6zXTItVIZ8M=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/mod@v0.4.1 h1:Kvvh58BN8Y9/lBi7hTekvtMpm07eUZ0ck5pRHpsMWrY=
    golang.org/x/sync@v0.0.0-20201020160332-67f06af15bc9 h1:SQFwaSi55rU7vdNs9Yr0Z324VNlrF+0wMqRXT4St8ck=
    golang.org/x/sys@v0.0.0-20210124154548-22da62e12c0c h1:VwygUrnw9jn88c4u8GD3rZQbqrP/tgas88tPUbBxQrk=
    golang.org/x/tools@v0.1.1-0.20210210013322-d4590503678b h1:uapRsD3vvVzFdGVOgFK3KMVqeDpdrxqhe5/UNZS6mwg=
    golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
    honnef.co/go/tools@v0.1.1 h1:EVDuO03OCZwpV2t/tLLxPmPiomagMoBOgfPt0FM+4IY=
    mvdan.cc/gofumpt@v0.1.0 h1:hsVv+Y9UsZ/mFZTxJZuHVI6shSQCtzZ11h1JEFPAZLw=
    mvdan.cc/xurls/v2@v2.2.0 h1:NSZPykBXJFCetGZykLAxaL6SIpvbVy/UFEniIfHAa8A=

---

I am ready to provide any additional information.

EDIT: Possibly related to #36531?

[gopherbot]

Change https://golang.org/cl/291192 mentions this issue: internal/lsp: refactor go command error handling

[heschi]

That CL was not supposed to close this issue, but it might be worth checking if it incidentally fixed it.

[ainar-g]

Doesn't seem like it, unfortunately. I can still reproduce the original issue.

[heschi]

Thanks for confirming, I'll take a look when I get a chance.

[heschi]

I'm afraid I can't reproduce it, even with experimentalWorkspaceModule. I get a diagnostic on the appropriate line of the go.mod, as well as an "Error loading workspace" status message. Can you double-check that you're using a version with that CL included and upload a log? Sorry for the trouble.

[ainar-g]

@heschik, yes, I can still reproduce it. The --logfile option didn't work for me—the files turned out empty every time for some reason—, so I decided to instead use the “nuclear” option and just wget -E -k -r the debug output and then compress and attach them.

• good.tar.gz
• bad.tar.gz

Build info from info.html:

golang.org/x/tools/gopls master
    golang.org/x/tools/gopls@v0.0.0-20210218195900-9eb353543b38 h1:vmOMMCKj9UAuhJ61XbbL2YWVaSREl71VJi+goBsaDZo=
    github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/google/go-cmp@v0.5.4 h1:L8R9j+yAqZuZjsqh/z+F1NCffTKKLShY6zXTItVIZ8M=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/mod@v0.4.1 h1:Kvvh58BN8Y9/lBi7hTekvtMpm07eUZ0ck5pRHpsMWrY=
    golang.org/x/sync@v0.0.0-20201020160332-67f06af15bc9 h1:SQFwaSi55rU7vdNs9Yr0Z324VNlrF+0wMqRXT4St8ck=
    golang.org/x/sys@v0.0.0-20210124154548-22da62e12c0c h1:VwygUrnw9jn88c4u8GD3rZQbqrP/tgas88tPUbBxQrk=
    golang.org/x/tools@v0.1.1-0.20210218195900-9eb353543b38 h1:AOnqnOc/zrpEP0Jf7fGER9N5n4xWmoQg7FvdiH78xeQ=
    golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
    honnef.co/go/tools@v0.2.0-0.dev.0.20210217134301-16f40c10b7a4 h1:5KJ5c2KSzEy2O2ANwZCbZEEyicSDg7yXvfrlZT6dMAI=
    mvdan.cc/gofumpt@v0.1.0 h1:hsVv+Y9UsZ/mFZTxJZuHVI6shSQCtzZ11h1JEFPAZLw=
    mvdan.cc/xurls/v2@v2.2.0 h1:NSZPykBXJFCetGZykLAxaL6SIpvbVy/UFEniIfHAa8A=

Please let me know if there is any other useful info I can provide.

[heschi]

Interesting approach. Happened to work here. From bad/client/1.html:

/tmp/gomod/go.mod:
   (0:0-0:0)"unknown directive: package"(source:"syntax",code:"",severity:Error,snapshot:2,type:FromSource)
   (0:0-0:0)"/tmp/gomod/go.mod:1: unknown directive: package"(source:"go list",code:"",severity:Error,snapshot:2,type:FromSource)

So I'm not quite sure what to tell you. It appears we're generating errors at least to some extent, but they're not showing up in the client?

@findleyr, can you shed any light on this since you know vim stuff?

[ainar-g]

@heschik, I've done some more digging, and apparently gopls sends a window/logMessage request rather than a more appropriate window/showMessage one. In the verbose Neovim logs:

[ DEBUG ] 2021-02-19T00:47:46+0300 ] /usr/share/nvim/runtime/lua/vim/lsp.lua:500 ]	"notification"	"window/logMessage"	{  message = "2021/02/19 00:47:44 errors loading workspace: /tmp/gomod/go.mod:1: unknown directive: package\n\tsnapshot=1\n\tdirectory=file:///tmp/gomod\n",  type = 1}
[ DEBUG ] 2021-02-19T00:47:46+0300 ] /usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"window/logMessage"	{  client_id = 1,  params = {    message = "2021/02/19 00:47:44 errors loading workspace: /tmp/gomod/go.mod:1: unknown directive: package\n\tsnapshot=1\n\tdirectory=file:///tmp/gomod\n",    type = 1  }}

From what I can tell, including this message by @stamblerre, window/logMessage is for logging whilewindow/showMessage is for actually showing a message to the user. Am I wrong here?