Lsp-mode: LSP :: no token.File for file:/// error on making change to .go file

Created on 13 May 2020  ยท  5Comments  ยท  Source: emacs-lsp/lsp-mode

This appears to be the same issue raised a few days ago here: https://github.com/emacs-lsp/lsp-mode/issues/1623

Environment

Running spacemacs off the develop branch, I believe everything is up to date:

josh/repos/test  (:|โœ”)$  
go version
go version go1.14.2 linux/amd64
josh/repos/test  (:|โœ”)$  
uname -r
5.6.12-arch1-1
josh/repos/test  (:|โœ”)$  
emacs -version
GNU Emacs 26.3
...
josh/repos/test  (:|โœ”)$  
gopls version
golang.org/x/tools/cmd/gopls master-cmd.gopls
    golang.org/x/tools@(devel)
/home/josh/.emacs.d  (develop|โœ”)$  
gpl
Already up to date.

steps to reproduce

  1. Create a simple project like this:
josh/repos/test  (:|โœ”)$  
tree
.
โ”œโ”€โ”€ go.mod
โ””โ”€โ”€ hello.go

0 directories, 2 files
josh/repos/test  (:|โœ”)$  
cat hello.go 
package hello

func Hello() string {
    return "Hello, world."
}
  1. Open go file and initialize lsp to the root of the project
  2. Make any change to the buffer

Note up until a change is made eveything appears to be working perfectly.

Debug Info

Toggling debug I see the following errors in the Messages buffer

[go] Setting lsp-diagnostic-package :none to enable golangci-lint support.
LSP :: Connected to [gopls:128966 status:starting].
LSP :: gopls:128966 initialized successfully
debug-on-error enabled.
LSP :: no parsed files for package example.com/hello
LSP :: no token.File for file:///home/josh/repos/test/hello.go [3 times]
LSP :: no parsed files for package example.com/hello
LSP :: no token.File for file:///home/josh/repos/test/hello.go [3 times]

Here's what the lsp-log buffer shows

Command "gopls" is present on the path.
Command "bingo" is not present on the path.
Command "go-langserver" is present on the path.
Command "gopls" is present on the path.
Command "bingo" is not present on the path.
Command "go-langserver" is present on the path.
Found the following clients for /home/josh/repos/test/hello.go: (server-id gopls, priority 0), (server-id go-ls, priority -2)
The following clients were selected based on priority: (server-id gopls, priority 0)
2020/05/12 16:04:45 Build info
----------
golang.org/x/tools/cmd/gopls master-cmd.gopls
    golang.org/x/tools@(devel)
    golang.org/x/[email protected] h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU=
    golang.org/x/[email protected] h1:9zdDQZ7Thm29KFXgAX/+yaf3eVbP7djjWp/dXAppNCc=

Go info
-------
go version go1.14.2 linux/amd64

GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/josh/.cache/go-build"
GOENV="/home/josh/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/josh/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/josh/repos/test/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-build020091299=/tmp/go-build -gno-record-gcc-switches"

2020/05/12 16:04:45 go/packages.Load
    package = example.com/hello
    files = [/home/josh/repos/test/hello.go]
2020/05/12 16:04:45 go/packages.Load
    packages = 1
2020/05/12 16:04:53 go/packages.Load
    packages = 0
2020/05/12 16:04:53 go/packages.Load
    packages = 1
2020/05/12 16:04:53 go/packages.Load
    package = example.com/hello
    files = [/home/josh/repos/test/hello.go]
2020/05/12 16:04:53 no package for file: no parsed files for package example.com/hello
2020/05/12 16:04:56 : line is beyond end of file 2

Most helpful comment

At least on Arch this is a bad solution:
Never ever remove/modify files from /usr/bin as these files should only be handled by the package manager.
Also I noticed that the official Arch package go-tools also contains this binary. (not only the package you linked)
So if you remove /usr/bin/gopls you get the problem back always when updating the go-tools package.

But I have a solution for this:
Just add your ~/go/bin path to the exec-path of emacs by adding this to your emacs configuration:
(setq exec-path (append '("/home/arch/go/bin") exec-path))
(and running M-x lsp-workspace-restart RET in emacs after that)

All 5 comments

@muirdm do you have a clue?

Thank you both very much, @muirdm that was the issue:

/home/josh (:|โœ”)$ which gopls /usr/bin/gopls /home/josh (:|โœ”)$ sudo rm /usr/bin/gopls /home/josh (:|โœ”)$ which gopls /home/josh/go/bin/gopls

Works beautifully now, looks like I installed at some point using this arch-linux package which appears to put the bin at /usr/bin/gopls.

At least on Arch this is a bad solution:
Never ever remove/modify files from /usr/bin as these files should only be handled by the package manager.
Also I noticed that the official Arch package go-tools also contains this binary. (not only the package you linked)
So if you remove /usr/bin/gopls you get the problem back always when updating the go-tools package.

But I have a solution for this:
Just add your ~/go/bin path to the exec-path of emacs by adding this to your emacs configuration:
(setq exec-path (append '("/home/arch/go/bin") exec-path))
(and running M-x lsp-workspace-restart RET in emacs after that)

Thanks

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lukertty picture lukertty  ยท  5Comments

dchneric picture dchneric  ยท  3Comments

axelson picture axelson  ยท  4Comments

alanz picture alanz  ยท  6Comments

sid-kap picture sid-kap  ยท  5Comments