go coverage highlights are not showing up after go mod

[chrisolsen]

When a go.mod file exists no test highlights are visible. When a simple go app is created with a main.go and main_test.go file highlights are visible. When I run go mod init app and run the tests again, the highlight disappears.

• After running Go: Test Project no coverage highlights are seen.
• Coverage highlights are still not seen after running Go: Toggle test coverage in test package then Go: Test Project
• Coverage results are always visible in the terminal when coverage is toggled back and forth.

GOPATH: /home/chris/.gvm/pkgsets/go1.11/global
OS: KDE Neon (Linux 4.15.0-33-generic #36~16.04.1-Ubuntu SMP Wed Aug 15 17:21:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux)
VSCode: 1.27.1
GO: 1.11

[ramya-rao-a]

#1532 is tracking all the features that need to be fixed when using Go modules. Can you please add this there?

[ramya-rao-a]

Re-opening this, as this can be dealt with separately.

The problem is that the coverage report generated by go test, contains the package import path.
In the world of GOPATH, the package import path would always be the part of the file path as well.
That is no longer the case when modules are being used.

For example, below is an example of the coverage data:

mode: set
github.com/ramya-rao-a/hello/bye.go:9.12,13.2 2 0
github.com/ramya-rao-a/hello/hello.go:9.13,11.2 1 0
github.com/ramya-rao-a/hello/hello.go:13.19,15.2 1 1

In the world of GOPATH, I could add coverage to the file whose path ends with github.com/ramya-rao-a/hello/bye.go, but in the world of modules, the file in question need not have the import path in its path.

@bcmills Would it be a reasonable request to the Go tool, to have the coverage data contain the absolute paths of the files?

[bcmills]

I'll have to give it some thought. Absolute paths would make the coverage results less cacheable, e.g. for distributed build systems where two users may run coverage with the same source versions but different absolute paths.

[egonelbre]

For converting the converprofile to absolute paths, a minimal tool can be used https://gist.github.com/egonelbre/6b0e3048bb28423d52a62ed1633e693d

This could be a workaround until a decision is reached for the coverage tool.

[ramya-rao-a]

Thanks @egonelbre
I am hesitant to add yet another tool that the user will have to install to enable this feature, when we have most of the information we need to deduce the absolute path already with us.

[ramya-rao-a]

I have pushed a fix to master. Can folks here try out the beta version of this extension and confirm that the fix works?

[mrg0lden]

@ramya-rao-a

UPDATE: I found that these errors are due to changes in golang.org/x/tools/go/packages

I tried to install the forked tools after installing the latest beta

I got these errors

  gocode-gomod
  godef-gomod

Installing github.com/stamblerre/gocode FAILED
Installing github.com/ianthehat/godef FAILED

2 tools failed to install.

gocode-gomod:
Error: Command failed: C:\Go\bin\go.exe build -o C:\Users\User\go\bin\gocode-gomod.exe github.com/stamblerre/gocode
# github.com/stamblerre/gocode/internal/suggest
..\..\..\..\go\src\github.com\stamblerre\gocode\internal\suggest\suggest.go:138:3: cannot use func literal (type func(*token.FileSet, string) (*ast.File, error)) as type func(*token.FileSet, string, []byte) (*ast.File, error) in field value
# github.com/stamblerre/gocode/internal/suggest
..\..\..\..\go\src\github.com\stamblerre\gocode\internal\suggest\suggest.go:138:3: cannot use func literal (type func(*token.FileSet, string) (*ast.File, error)) as type func(*token.FileSet, string, []byte) (*ast.File, error) in field value

godef-gomod:
Error: Command failed: C:\Go\bin\go.exe build -o C:\Users\User\go\bin\godef-gomod.exe github.com/ianthehat/godef
# github.com/ianthehat/godef
..\..\..\..\go\src\github.com\ianthehat\godef\godef.go:134:3: cannot use parser (type func(*token.FileSet, string) (*ast.File, error)) as type func(*token.FileSet, string, []byte) (*ast.File, error) in field value
# github.com/ianthehat/godef
..\..\..\..\go\src\github.com\ianthehat\godef\godef.go:134:3: cannot use parser (type func(*token.FileSet, string) (*ast.File, error)) as type func(*token.FileSet, string, []byte) (*ast.File, error) in field value

go version
go version go1.11.1 windows/amd64
go env

set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\User\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\User\go
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\User\Projects\attendance\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\User\AppData\Local\Temp\go-build701171602=/tmp/go-build -gno-record-gcc-switche

[egonelbre]

@mrg0lden the package interfaces changed so the programs need adjusting (caused by commit golang/tools@2f1727f)

[mrg0lden]

Well, I managed to compile both of them, but now I get a notification that says: "Auto-completion feature failed as an older gocode process is still running. Please kill the running process for gocode and try again.".

UPDATE: I killed the process, rebooted the system, but still getting the same error.

[ramya-rao-a]

@mrg0lden This issue is tracking the problem with code coverage when using Go modules. Based on what you are saying above, your problem has nothing to do with code coverage. Or am I missing something?

Otherwise, the issue with installing the forks is being tracked in #1979

[mrg0lden]

@ramya-rao-a Yeah you're right. Sorry, got excited with the update and thought it has to do with auto-completion.

[ramya-rao-a]

@mrg0lden No problem, #1979 is now resolved. Please see
#1979 (comment)

[ramya-rao-a]

This is fixed in the latest update to the Go extension (0.6.91)