Vim-go: errors don't appear on save with go 1.13

[g00nix]

What did you do? (required: The issue will be closed when not provided)

I update to go 1.13.

What did you expect to happen?

Everything to work fine.

What happened instead?

Vim is not showing errors any more

Configuration (MUST fill this out):

vim-go version:

1.20-1

vimrc you used to reproduce (use a minimal vimrc with other plugins disabled; do not link to a 2,000 line vimrc):

vimrc

source $VIMRUNTIME/defaults.vim

set mouse=""

set nu

set laststatus=2

set t_Co=256

set wildmode=longest,list

let g:powerline_pycmd = 'py3'

nnoremap  

nnoremap  

nnoremap  

nnoremap  

nnoremap  :terminal % 


set splitbelow

set splitright

set shiftwidth=2

set expandtab

set softtabstop=2

let g:indentLine_color_term = 239

let g:ansible_unindent_after_newline = 1

let g:go_auto_sameids = 1

let g:go_highlight_array_whitespace_error = 1

let g:go_highlight_chan_whitespace_error = 1

let g:go_highlight_extra_types = 1

let g:go_highlight_space_tab_error = 1

let g:go_highlight_trailing_whitespace_error = 0

let g:go_highlight_operators = 1

let g:go_highlight_functions = 1

let g:go_highlight_function_parameters = 1

let g:go_highlight_function_calls = 1

let g:go_highlight_types = 1

let g:go_highlight_fields = 1

let g:go_highlight_build_constraints = 1

let g:go_highlight_generate_tags = 1

let g:go_highlight_string_spellcheck = 1

let g:go_highlight_format_strings = 1

let g:go_highlight_variable_declarations = 1

let g:go_highlight_variable_assignments = 1

colorscheme pablo

hi Folded ctermbg=232 ctermfg=33

set foldmethod=syntax

set foldnestmax=1

let g:go_fmt_experimental = 1

Vim version (first three lines from :version):

8.1.1968-1

Go version (go version):

go1.13

Go environment

go env Output:

GO111MODULE=""

GOARCH="amd64"

GOBIN=""

GOCACHE="/home/gunix/.cache/go-build"

GOENV="/home/gunix/.config/go/env"

GOEXE=""

GOFLAGS=""

GOHOSTARCH="amd64"

GOHOSTOS="linux"

GONOPROXY=""

GONOSUMDB=""

GOOS="linux"

GOPATH="/home/gunix/.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="0"

GOMOD="/home/gunix/git/gun1x/spiderweber/spider/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build214595135=/tmp/go-build -gno-record-gcc-switches"

[g00nix]

As can be seen in the picture, I don't get any errors pointing the row on the left side of the line numbers.

[bhcleek]

The errors you're expecting to see on save would be compilation errors, and since the file isn't compiled on save, I'm not clear on why you would expect to see the errors when saving the file. What am I missing? 🤔

[g00nix]

The errors you're expecting to see on save would be compilation errors, and since the file isn't compiled on save, I'm not clear on why you would expect to see the errors when saving the file. What am I missing?

Before the upgrade, I was getting errors on save.

[g00nix]

@bhcleek syntax errors are presented at 1:35 in this video

[bhcleek]

I'll see what I can do, but the errors in that video are different from what you're seeing. In the video, the errors are for an undeclared variable. In the case you've presented, it's a type that's not defined.

I'll see what I can do, but it's possible that this is a result of a change to gofmt.

[g00nix]

the errors are for an undeclared variable

[bhcleek]

Thanks, I'll take a closer look in the next couple of days.

[bhcleek]

@gun1x I've taken another look at this.

The error you were seeing on save was never from gofmt from what I can tell. The _only_ way that I can duplicate showing compilation errors on save is if g:go_metalinter_autosave is enabled, g:go_metalinter_command is set to gometalinter, and Go 1.12.9 or lower is installed.

After a lot of digging, I tracked the problem you reported down to a change in go vet's output. By default, vim-go calls gometalinter with the vet linter when g:go_metalinter_autosave is set.
Prior to Go 1.13, go vet's output (and consequently gometalinter's) looked something like this: ./main.go:6:2: undefined: foo. With Go 1.13, though, go vet's output includes a prefix before the file location: vet: ./main.go:6:2: undeclared name: foo, which breaks gometalinter's expectations.

Since gometalinter is archived and deprecated by its owner, there's not much we can do here; gometalinter is effectively EOL, and the next release of vim-go will no longer use it for the default g:go_metalinter_command.

The one bit I'm confused about though, is that I don't see let g:go_metalinter_autosave=1 in your vimrc. 🤔

[bhcleek]

Despite finding a workaround for gometalinter, I'm re-opening so that we can finish the conversation just in case you have something else going on

[g00nix]

@bhcleek Thank you for your interest on the subject.

Go 1.12

Yea, downgrading back to pacman -U /var/cache/pacman/pkg/go-2:1.12.9-1-x86_64.pkg.tar.xz restores old behavior:

This helps a lot with writing code, as you don't have to do GoRun and manually check the lines where problem appears, and you just get an arrow and the error text in the bottom of the screen.
This happens without setting let g:go_metalinter_autosave=1. I did :let g:go_metalinter_autosave and it returned E121: Undefined variable: g:go_metalinter_autosave.

Go 1.13

On go 1.13 I get syntax errors, with proper arrows where it happens, like this:

However syntax errors are not enough. vim-go helps a lot more with coding than just syntax error.

It's really hard to troubleshoot using this:

# gitlab.com/spiderweber/spider
./knot_client.go:20:26: undefined: ipport
./knot_client.go:36:5: cannot use mypackage.Knot literal (type mypackage.Knot) as type *mypackage.Knot in field value
./knot_client.go:37:17: knot.Name undefined (type int has no field or method Name)
./knot_client.go:38:17: knot.IP undefined (type int has no field or method IP)
./knot_client.go:39:17: knot.Port undefined (type int has no field or method Port)
./knot_client.go:40:17: knot.Wings undefined (type int has no field or method Wings)

This feels like the difference between Morrowind and Oblivion. It's horrible to find quests without arrows.

future solution for go 1.13

If the next release of vim-go will solve the problem by using something else instead of gometalinter, I can stay on go 1.13 and use the git version of vim-go and enable whatever you tell me to, test it and report back. I've been working for years with vim and I would rather help out to solve this than use anything else.

[bhcleek]

I did :let g:go_metalinter_autosave and it returned E121: Undefined variable: g:go_metalinter_autosave.

That's odd. I'm not sure how you're getting this behavior with Go 1.12 🤔

In any case, I'd recommend not using :GoRun for this. Though it will do what you want, it's a bit of an abuse of of the command and won't really be much better than simply doing :GoBuild.

You _could_ run :GoBuild on save pretty easily by adding autocmd <buffer> BufWritePre go#cmd#Build(0), but I think you can do better.

The typecheck linter will restore the behavior you seek, so you can add this to your vimrc (assuming you're using the latest current master or otherwise have let g:go_metalinter_command='golangci-lint' in your vimrc:

let g:go_metalinter_autosave=1
let g:go_metalinter_autosave_enabled=['golint', 'govet', 'typecheck']

[bhcleek]

I should also point out that I expect v1.22 of vim-go (i.e. the release after next) to have automatic, real time support for identifying this kinds of errors, so you'll be told about these kinds of errors in real time, without even having to save. Now that I think about it, I could modify vim-go to provide it on save no pretty easily, because gopls provides the information already, so I'll look into doing that first and will create a patch to do just that soon after releasing vim-go v1.21.

On go 1.13 I get syntax errors, with proper arrows where it happens, like this:

Those arrows aren't coming from vim-go. Are you also using one of the lsp plugins?

[g00nix]

Those arrows aren't coming from vim-go. Are you also using one of the lsp plugins?

I install my plugins from AUR instead of using a vim package manager. These are the vim packages which I installed:

ansible-vim-git 2.0.r6.ge5b9acf-1
powerline-vim 2.7-3
vim 8.1.1968-1
vim-ale 2.5.0-1
vim-go 1.20-1
vim-indentline-git r199.80f4acd-1
vim-runtime 8.1.1968-1

One of them might throw the syntax errors. I suspect ale.

[g00nix]

The typecheck linter will restore the behavior you seek, so you can add this to your vimrc (assuming you're using the latest current master or otherwise have let g:go_metalinter_command='golangci-lint' in your vimrc:

let g:go_metalinter_autosave=1
let g:go_metalinter_autosave_enabled=['golint', 'govet', 'typecheck']

both on vim-go 1.20-1 and on vim-go-git 20150710-1 (from here) I can add

let g:go_metalinter_autosave=1
let g:go_metalinter_autosave_enabled=['golint', 'govet', 'typecheck']
let g:go_metalinter_command='golangci-lint'

To get warnings at the bottom of vim:

But without arrows. This is still awesome, though, cause typecheck will display all errors and you can actually navigate to the error, hit enter and it will take you to the problematic line.

I however do not suggest it on vim-go 1.20-1 cause it seems to bug out when saving with no errors. It randomly opens the hello world template. Strange, right?

[bhcleek]

What do you mean by vim-go 1.20-1?

[g00nix]

What do you mean by vim-go 1.20-1?

I don't get the question. If you ask what's up with -1, it's probably just this but pacman adds the -1.

If you are asking about the strange behavior. I was hitting :w and it was randomly closing the active file and opening the hello world template. I tried again on another system today and I don't see this problem. Maybe it was some strange problem isolated to what I tried yesterday. Please just ignore :-D

[bhcleek]

yeah, that's weird, but since we're getting ready to release v1.21. and v1.20 is pretty old, I'm inclined to not worry about.

I think we've come to an end for this conversation and should close this issue then unless there's still something unresolved for you. WDYT?

[g00nix]

I think we've come to an end for this conversation and should close this issue then unless there's still something unresolved for you. WDYT?

You've been really helpful. I think anybody interested in the topic will also find all required information here. Ticket can be closed, yes.

Have fun releasing v1.21!

[g00nix]

Ticket update

For the people that got to this ticket via google and wonder how to get your vim-go to actually show an errors, at the time of this comment you can use the following config in your .vimrc:

nnoremap <F6> :w <CR> :GoTestCompile <CR> <CR>
inoremap <F6> <ESC> :w <CR> :GoTestCompile <CR> <CR>
let g:go_metalinter_autosave=1
let g:go_metalinter_autosave_enabled=['golint', 'govet']

When you want to save and check the code, hit F6.

[bhcleek]

I believe this is fully resolved on master now via #2706, #2708, and #2720 without having to resort to any of the workarounds mentioned above. The one caveat I'd mention is that #2722 identifies some edge cases that I'm still trying to find an elegant solution for.