search

saibing / bingo

Bingo is a Go language server that speaks Language Server Protocol.
MIT License
495 stars 25 forks source link

switching to gopls issue? #181

Closed vbauerster closed 5 years ago

vbauerster commented 5 years ago

First of all thank you for your work. I'm using bingo with kak-lsp and it works out of the box. As you mentioned in latest readme, we should be switching to gopls, so I decided to give it a try. Unfortunately it didn't work. I suppose it's because bingo use -mode stdio by default, but there is no such option in gopls, correct me if I'm wrong. So my question what is equivalent command for gopls to run in stdio communication mode?

saibing commented 5 years ago

@vbauerster

if run gopls without any flag, the default communicate mode is stdio .

you can set -listen flag to use tcp mode.

  -listen string
        address on which to listen for remote connections

gopls has -mode flag, but not effect

  -mode string
        no effect
inliquid commented 5 years ago

@saibing on branch bingo of your forked gopls repo main func of cmd/gopls only references to golang.org, and nothing related with github.com/saibing/tools. Am I missing something?

package main // import "golang.org/x/tools/cmd/gopls"

import (
    "context"
    "os"

    "golang.org/x/tools/internal/lsp/cmd"
    "golang.org/x/tools/internal/tool"
)

func main() {
    tool.Main(context.Background(), &cmd.Application{}, os.Args[1:])
}
saibing commented 5 years ago

@inliquid

I forked tools that modue name is golang.org/x/tools. It is a mirror site of 'golang.org/x/tools'

mbana commented 5 years ago

Seems to work fine for me. The only thing is the tests do not pass

$ gotest -parallel=8 -count=1 -v ./internal/lsp/...
=== RUN   TestLSP
=== RUN   TestLSP/GOPATH
=== RUN   TestLSP/GOPATH/Completion
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
    panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x4308b99]

goroutine 37 [running]:
testing.tRunner.func1(0xc0001ac300)
    /usr/local/go/src/testing/testing.go:830 +0x388
panic(0x439e540, 0x472bfb0)
    /usr/local/go/src/runtime/panic.go:522 +0x1b5
golang.org/x/tools/internal/lsp/cache.(*importer).typeCheck(0xc0001a2880, 0xc00022a780, 0x24, 0x0, 0x0, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cache/check.go:280 +0x799
golang.org/x/tools/internal/lsp/cache.(*View).parse(0xc0001180f0, 0x44ab640, 0xc0000ac000, 0xc00053c000, 0x0, 0x0, 0x0, 0x0, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cache/check.go:53 +0x2a5
golang.org/x/tools/internal/lsp/cache.(*File).GetToken(0xc00053c000, 0x44ab640, 0xc0000ac000, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cache/file.go:65 +0xc3
golang.org/x/tools/internal/lsp.newColumnMap(0x44ab640, 0xc0000ac000, 0x44aab40, 0xc0001180f0, 0xc00021dd40, 0x84, 0xc00021dd40, 0x84, 0x7d, 0x0, ...)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/format.go:60 +0xcb
golang.org/x/tools/internal/lsp.(*Server).Completion(0xc00009d500, 0x44ab640, 0xc0000ac000, 0xc00025fbf8, 0x1, 0xc000527930, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/server.go:316 +0x9b
golang.org/x/tools/internal/lsp.completions.test(0xc000442900, 0xc0001ac300, 0xc000188c40, 0xc00009d500, 0xc0004428d0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/lsp_test.go:294 +0x336
golang.org/x/tools/internal/lsp.testLSP.func3(0xc0001ac300)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/lsp_test.go:115 +0x144
testing.tRunner(0xc0001ac300, 0xc00019f6b0)
    /usr/local/go/src/testing/testing.go:865 +0xc0
created by testing.(*T).Run
    /usr/local/go/src/testing/testing.go:916 +0x357
FAIL    golang.org/x/tools/internal/lsp 0.278s
?       golang.org/x/tools/internal/lsp/cache   [no test files]
=== RUN   TestCommandLine
=== RUN   TestCommandLine/GOPATH
=== RUN   TestCommandLine/GOPATH/Completion
=== RUN   TestCommandLine/GOPATH/Diagnostics
=== RUN   TestCommandLine/GOPATH/Format
=== RUN   TestCommandLine/GOPATH/Definitions
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
    panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x4389e69]

goroutine 1357 [running]:
testing.tRunner.func1(0xc000203c00)
    /usr/local/go/src/testing/testing.go:830 +0x388
panic(0x45d1200, 0x4b7c080)
    /usr/local/go/src/runtime/panic.go:522 +0x1b5
golang.org/x/tools/internal/lsp/cache.(*importer).typeCheck(0xc013e12900, 0xc0000a31d0, 0x27, 0x0, 0x0, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cache/check.go:280 +0x799
golang.org/x/tools/internal/lsp/cache.(*View).parse(0xc000c462d0, 0x4770740, 0xc0000d4000, 0xc0157aa460, 0x0, 0x0, 0x0, 0x0, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cache/check.go:53 +0x2a5
golang.org/x/tools/internal/lsp/cache.(*File).GetToken(0xc0157aa460, 0x4770740, 0xc0000d4000, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cache/file.go:65 +0xc3
golang.org/x/tools/internal/lsp/cmd.(*definition).Run(0xc012c12f90, 0x4770740, 0xc0000d4000, 0xc015f822e0, 0x1, 0x2, 0x0, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cmd/definition.go:70 +0x1e8
golang.org/x/tools/internal/tool.Main.func2(0x0, 0x4772e40, 0xc012c12f90, 0x4770740, 0xc0000d4000, 0xc00851fbc0, 0x0, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/tool/tool.go:131 +0xb7
golang.org/x/tools/internal/tool.Main(0x4770740, 0xc0000d4000, 0x4772e40, 0xc012c12f90, 0xc015f822e0, 0x1, 0x2)
    /Users/mbana/dev/banaio/github/tools/internal/tool/tool.go:132 +0x243
golang.org/x/tools/internal/lsp/cmd.(*query).Run(0xc019444880, 0x4770740, 0xc0000d4000, 0xc015f822e0, 0x2, 0x3, 0x0, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cmd/query.go:59 +0x262
golang.org/x/tools/internal/tool.Main.func2(0x0, 0x4772e80, 0xc019444880, 0x4770740, 0xc0000d4000, 0xc00851fb60, 0x0, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/tool/tool.go:131 +0xb7
golang.org/x/tools/internal/tool.Main(0x4770740, 0xc0000d4000, 0x4772e80, 0xc019444880, 0xc015f822d0, 0x2, 0x3)
    /Users/mbana/dev/banaio/github/tools/internal/tool/tool.go:132 +0x243
golang.org/x/tools/internal/lsp/cmd.(*Application).Run(0xc0157e0480, 0x4770740, 0xc0000d4000, 0xc015f822d0, 0x3, 0x3, 0x0, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cmd/cmd.go:102 +0x35c
golang.org/x/tools/internal/tool.Main.func2(0xc0157e0480, 0x4772d80, 0xc0157e0480, 0x4770740, 0xc0000d4000, 0xc00851fb00, 0x0, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/tool/tool.go:131 +0xb7
golang.org/x/tools/internal/tool.Main(0x4770740, 0xc0000d4000, 0x4772d80, 0xc0157e0480, 0xc015f822c0, 0x3, 0x4)
    /Users/mbana/dev/banaio/github/tools/internal/tool/tool.go:132 +0x243
golang.org/x/tools/internal/lsp/cmd_test.definitions.testDefinitions.func1()
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cmd/definition_test.go:105 +0x6a
golang.org/x/tools/internal/lsp/cmd_test.captureStdOut(0x477a860, 0xc000203c00, 0xc0000e3c68, 0x0, 0x0)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cmd/cmd_test.go:174 +0x13b
golang.org/x/tools/internal/lsp/cmd_test.definitions.testDefinitions(0xc000458cc0, 0xc000203c00, 0xc0001aea80)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cmd/definition_test.go:104 +0x650
golang.org/x/tools/internal/lsp/cmd_test.testCommandLine.func5(0xc000203c00)
    /Users/mbana/dev/banaio/github/tools/internal/lsp/cmd/cmd_test.go:98 +0x61
testing.tRunner(0xc000203c00, 0xc019444680)
    /usr/local/go/src/testing/testing.go:865 +0xc0
created by testing.(*T).Run
    /usr/local/go/src/testing/testing.go:916 +0x357
FAIL    golang.org/x/tools/internal/lsp/cmd 2.695s
=== RUN   TestDiff
--- PASS: TestDiff (0.00s)
PASS
ok      golang.org/x/tools/internal/lsp/diff    0.006s
=== RUN   TestIsHeading
--- PASS: TestIsHeading (0.00s)
=== RUN   TestBlocks
--- PASS: TestBlocks (0.00s)
=== RUN   TestToText
--- PASS: TestToText (0.00s)
=== RUN   TestEmphasize
--- PASS: TestEmphasize (0.00s)
=== RUN   TestEmphasizeMarkdown
--- PASS: TestEmphasizeMarkdown (0.00s)
=== RUN   TestPairedParensPrefixLen
--- PASS: TestPairedParensPrefixLen (0.00s)
=== RUN   Test
--- PASS: Test (0.02s)
=== RUN   TestSynopsis
--- PASS: TestSynopsis (0.00s)
=== RUN   TestExamples
--- FAIL: TestExamples (0.00s)
    example_test.go:184: KeyValueTopDecl: got Play == "package main\n\nimport (\n\t\"fmt\"\n)\n\nvar keyValueTopDecl = struct {\n\ta string\n\tb int\n}{\n\ta: \"B\",\n\tb: 2,\n}\n\nfunc main() {\n\tfmt.Print(keyValueTopDecl)\n}\n", want "<nil>"
FAIL
FAIL    golang.org/x/tools/internal/lsp/godocmd 0.035s
?       golang.org/x/tools/internal/lsp/project [no test files]
?       golang.org/x/tools/internal/lsp/protocol    [no test files]
?       golang.org/x/tools/internal/lsp/protocol/preserve   [no test files]
?       golang.org/x/tools/internal/lsp/source  [no test files]

Version:

$ git --no-pager log -n1
commit d763d30558657d956bfe1e1f2c0481d6653635a5 (HEAD -> bingo_master, bingo/bingo)
Author: saibing <saibingdeng@gmail.com>
Date:   Sun Mar 31 13:23:52 2019 +0800

    x/tools/internal/lsp: update coc.nvim config guide
vbauerster commented 5 years ago

I have message no room in queue from gopls when using with kak-lsp.

s-kostyaev commented 5 years ago

I have message no room in queue from gopls when using with kak-lsp.

Same with emacs & lsp-mode

shuxiao9058 commented 5 years ago

I have message no room in queue from gopls when using with kak-lsp.

Same with emacs & lsp-mode

the same error too.

saibing commented 5 years ago

@stamblerre @s-kostyaev @vbauerster @shuxiao9058

The error info come from here

Why only emacs has this problem?

shuxiao9058 commented 5 years ago

@saibing perhaps this was because the lsp-mode's bug.

refer https://github.com/emacs-lsp/lsp-mode/pull/737

s-kostyaev commented 5 years ago

@saibing there is another emacs lsp client implementation eglot but it has another issue:

%  gopls -port 9090
2019/03/29 12:43:00 method "DidChangeConfiguration" not yet implemented
panic: runtime error: index out of range

goroutine 35 [running]:
golang.org/x/tools/internal/lsp.(*server).Initialized.func1(0xc0000a4e00, 0x14c2620, 0xc0000a2010)
    /Users/feofan/go/src/golang.org/x/tools/internal/lsp/server.go:175 +0x301
created by golang.org/x/tools/internal/lsp.(*server).Initialized
    /Users/feofan/go/src/golang.org/x/tools/internal/lsp/server.go:155 +0x53
mbana commented 5 years ago

Maybe try a commit before this one https://github.com/golang/tools/commit/1f1f5f5d5753bd1efa20508d9cf76bf3d6549d7a? The commit linked to is the one that introduced the error message "no room in queue". I haven't seen this error in vscode-go though, I am just quoting what I am seeing from the code.

s-kostyaev commented 5 years ago

@saibing

Why only emacs has this problem?

Maybe this can help gopls.log

stamblerre commented 5 years ago

The reason this only broke Emacs is because, in this change, gopls began asking the client for its configuration. I guess Emacs doesn't support this behavior. It should be fixed in gopls now.

guidao commented 5 years ago

I updated to the latest version and the problem still exists. @stamblerre

s-kostyaev commented 5 years ago

@stamblerre latest master works some time with emacs & eglot lsp client but it panics very fast:

%  gopls -port 9090
panic: runtime error: slice bounds out of range

goroutine 19 [running]:
bufio.(*Reader).ReadSlice(0xc000084900, 0xc0055b730a, 0x0, 0x0, 0x13f7f80, 0xc012bd8090, 0xc0001aa000)
    /usr/local/Cellar/go/1.12/libexec/src/bufio/bufio.go:331 +0x22d
bufio.(*Reader).ReadBytes(0xc000084900, 0xa, 0xc0001efe00, 0xc00005e480, 0xc0001efe20, 0x100673f, 0xc0000ac060)
    /usr/local/Cellar/go/1.12/libexec/src/bufio/bufio.go:434 +0x70
bufio.(*Reader).ReadString(...)
    /usr/local/Cellar/go/1.12/libexec/src/bufio/bufio.go:474
golang.org/x/tools/internal/jsonrpc2.(*headerStream).Read(0xc00009ac60, 0x14c26a0, 0xc0000a2010, 0xc0000ac060, 0xc00c39af40, 0xc00c39af01, 0x0, 0x0)
    /Users/feofan/go/src/golang.org/x/tools/internal/jsonrpc2/stream.go:97 +0x88
golang.org/x/tools/internal/jsonrpc2.(*Conn).Run(0xc000168460, 0x14c26a0, 0xc0000a2010, 0x0, 0x0)
    /Users/feofan/go/src/golang.org/x/tools/internal/jsonrpc2/jsonrpc2.go:281 +0xee
created by golang.org/x/tools/internal/lsp/cmd.(*Serve).Run.func1
    /Users/feofan/go/src/golang.org/x/tools/internal/lsp/cmd/serve.go:79 +0xa8

eglot-gopls.log

stamblerre commented 5 years ago

Sorry about that, you're right we didn't actually fix the issue (I am able to reproduce). I'm going to investigate and follow up. I will post updates on https://github.com/golang/go/issues/31178 since this is a gopls issue.

colinlabs commented 5 years ago

@sibing saibing/tools can not support auto-completion with single .go file,only work with go.mod. how to fix ?

saibing commented 5 years ago

@colinlabs

gopls does not support single go file. You can open the folder that contain the single go file.

colinlabs commented 5 years ago

@saibing ,I create dir,and write a main.go file,it can not auto-completion when go-langserver enable with gopls or bingo.

image

saibing commented 5 years ago

@colinlabs

Is your directory under $GOPATH/src?

colinlabs commented 5 years ago

@saibing Not, outside of GOPATH

stamblerre commented 5 years ago

@colinlabs: you need to either be working inside of your $GOPATH or you need to be using modules (your directory should have a go.mod file) for gopls or bingo to work correctly.

colinlabs commented 5 years ago

@saibing @stamblerre go.useCodeSnippetsOnFunctionSuggest can not work in gopls or `bingo, is it?

stamblerre commented 5 years ago

We still need to connect the settings with VSCode’s, but you can set “gopls”: { “enablePlaceholders”: true } for the same behavior.

colinlabs commented 5 years ago

@stamblerre how to use this config? I got Unknown configuration setting image

stamblerre commented 5 years ago

@colinlabs: VSCode will complain but it should still work. Once we have a stable set of configs for gopls, we will merge them with the VSCode extension so that you don't get that error message.

apmckinlay commented 5 years ago

Not sure if it's related, but using the May 29 version of saibing/tools with vscode go on Mac and Windows, I get "no room in queue" and it stops working. I have to restart gopls. This happens consistently after a short period of editing. I am working outside GOPATH with go.mod

hyacinthus commented 5 years ago

"no room in queue" often appears... reload the vscode window will fix it in a while.

And there must be some memory leak, every gopls process will easy reach 1G memory.

hyacinthus commented 5 years ago

By the way, could you show struct type define when cursor hover on a "type"? By now, it only show the type comment, except hover on the type define line (in fact unnecessary here).

stamblerre commented 5 years ago

This "no room in queue" error seems to have come up recently in gopls, and we are investigating it. The hover should show both the documentation and the declaration for a type. If you have any specific issues with gopls, please open a new issue here: https://github.com/golang/go/issues.