Support Go Modules

[joefitzgerald]

Context: I maintain Atom's go-plus package for go support. I know @ramya-rao-a is also interested in ensuring vscode-go works well with go modules.

There are a variety of failure scenarios for the current master version of gocode when using go modules support (in particular without using vendor mode).

Over time, we may want to edit this issue to describe each of the failure modes and validate that they are fixed. My assumption is that the cache branch and a switch to use golang.org/x/tools/go/packages will both be required to get to completion. @mdempsky do you have specific plans here?

[myitcv]

@joefitzgerald thanks for creating this issue; you just beat me to it 👍

Linking back to the umbrella Go issue: golang/go#24661

@mdempsky FYI I intend to take a stab at adding support via go/packages over the weekend, unless you already have this covered?

[fatih]

I agree with @myitcv, we should use go/packages (see: https://godoc.org/golang.org/x/tools/go/packages). One thing to note is that this is not backward compatible:

- The implementation depends on the Go 1.11 go command; support for earlier versions will be added soon.

I didn't use go/packages yet, but we should be aware of this limitation.

[ikgo]

code below fix the problem.
internal/gbimporter/gbimporter.go
add import "golang.org/x/tools/go/packages"

func (i *importer) ImportFrom(path, srcDir string, mode types.ImportMode) (*types.Package, error) {
	buildDefaultLock.Lock()
	defer buildDefaultLock.Unlock()

	var src []string
	src = append(src, path)
	cfg := &packages.Config{
		Mode: packages.LoadTypes,
		Dir:  srcDir,
	}
	pkgs, err := packages.Load(cfg, src...)

	// origDef := build.Default
	// defer func() { build.Default = origDef }()

	// def := &build.Default
	// def.GOARCH = i.ctx.GOARCH
	// def.GOOS = i.ctx.GOOS
	// def.GOROOT = i.ctx.GOROOT
	// def.GOPATH = i.ctx.GOPATH
	// def.CgoEnabled = i.ctx.CgoEnabled
	// def.UseAllFiles = i.ctx.UseAllFiles
	// def.Compiler = i.ctx.Compiler
	// def.BuildTags = i.ctx.BuildTags
	// def.ReleaseTags = i.ctx.ReleaseTags
	// def.InstallSuffix = i.ctx.InstallSuffix

	// def.SplitPathList = i.splitPathList
	// def.JoinPath = i.joinPath

	// var result, err = i.underlying.ImportFrom(path, srcDir, mode)
	if len(pkgs) > 0 {
		return pkgs[0].Types, nil
	}
	return nil, err
}

[ikgo]

working fork https://github.com/ikgo/gocode.git
check of go.mod existence added. in case doesn't exists the original code running

compatible with go 1.11 only

[myitcv]

Linking back to golang/go#24661

[myitcv]

@ikgo thanks for taking a look at this. I stopped my investigation after speaking to @ianthehat at GopherCon. Someone in his team is already working on helping to fix gocode, along with a number of other tools. See the issue linked in my previous comment, and also the group https://groups.google.com/forum/#!forum/golang-tools which arose from our discussions at GopherCon, in particular https://groups.google.com/d/msg/golang-tools/wNwFBDeZxhE/XFqiXQisBAAJ which are my notes from the sessions.