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: bad go.mod affects anayses but not formatting; no errors in logs #44204

Closed
ainar-g opened this issue Feb 10, 2021 · 10 comments
Closed

Comments

@ainar-g
Copy link
Contributor

@ainar-g ainar-g commented Feb 10, 2021

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 gopherbot added this to the Unreleased milestone Feb 10, 2021
@stamblerre stamblerre modified the milestones: Unreleased, gopls/v1.0.0 Feb 10, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented Feb 11, 2021

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

@heschi
Copy link
Contributor

@heschi heschi commented Feb 16, 2021

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

@ainar-g
Copy link
Contributor Author

@ainar-g ainar-g commented Feb 16, 2021

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

@heschi
Copy link
Contributor

@heschi heschi commented Feb 16, 2021

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

@heschi
Copy link
Contributor

@heschi heschi commented Feb 18, 2021

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
Copy link
Contributor Author

@ainar-g ainar-g commented Feb 18, 2021

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

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

@heschi heschi commented Feb 18, 2021

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
Copy link
Contributor Author

@ainar-g ainar-g commented Feb 18, 2021

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

@heschi
Copy link
Contributor

@heschi heschi commented Feb 18, 2021

That is debug logging, not user-facing. showMessage is a modal dialog and definitely not appropriate here. gopls is publishing user-facing diagnostics that your editor is not showing; you can see them if you enable rpc.trace and in the debug page I mentioned above.

@ainar-g
Copy link
Contributor Author

@ainar-g ainar-g commented Feb 18, 2021

It seems like you are correct. Maybe some kind of an issue with how Neovim handles diagnostics from buffers that aren't loaded and files that aren't open. I'm going to close this issue and keep digging. Sorry for the noise.

@ainar-g ainar-g closed this Feb 18, 2021
@stamblerre stamblerre removed this from the gopls/v1.0.0 milestone Feb 18, 2021
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
4 participants