can't find definition which in same package but same file when using modules with gopls

[jeffzhangme]

Steps to Reproduce:

1. create main.go and lib.go in gomod project main package

main.go

package main

import "fmt"

func main() {
	s := LibStruct{}
	fmt.Println(s)
}

lib.go

package main

type LibStruct struct {
	T string
}

2. code complete and find definition fail when using LibStruct in main.go

environment
go version go1.12.7 darwin/amd64
vscode-go 0.11.4
Code 1.36.1

[stamblerre]

@jeffzhangme: If this is a gopls issue, please open an issue in the Go issue tracker. Please also add your gopls logs for this situation - in particular, can you share the output of running gopls -rpc.trace -v check main.go in your example?

[jeffzhangme]

@stamblerre: I'm not sure if it's gopls problem, if use go vet with "go.vetOnSave": "package" and "diagnostics": false this seems normal, but use gopls and set "diagnostics": true there are some problems(doesn't affect go build):

It's output of running gopls -rpc.trace -v check main.go:

2019/08/03 11:12:44 Info:36.897843ms for GOROOT=/usr/local/Cellar/go/1.12.7 GOPATH=/xxx/gopath12: GO111MODULE=on PWD=/xxx/VscodeProjects/go-module-demo go "list" "-e" "-json" "-compiled=true" "-test=true" "-export=false" "-deps=true" "-find=false" "--" "builtin", stderr: <<>>
2019/08/03 11:12:44 Info:Build info
----------
version v0.1.3-cmd.gopls, built in $GOPATH mode

Go info
-------
go version go1.12.7 darwin/amd64

GOARCH="amd64"
GOBIN=""
GOCACHE="/xxx/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/xxx/gopath12"
GOPROXY="https://goproxy.io"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.7"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.7/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/xxx/go-module-demo/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/cg/d3_m01tj5wn5kd7g2f76mywm0000gn/T/go-build291429809=/tmp/go-build -gno-record-gcc-switches -fno-common"
2019/08/03 11:12:45 Info:157.458131ms for GOROOT=/usr/local/Cellar/go/1.12.7 GOPATH=/xxx/gopath12:/xxx/GoWorkspace GO111MODULE=on PWD=/xxx/VscodeProjects/go-module-demo go "list" "-e" "-json" "-compiled=true" "-test=true" "-export=false" "-deps=true" "-find=false" "--" "/xxx/VscodeProjects/go-module-demo", stderr: <<>>
2019/08/03 11:12:45 Info:go/packages.Load
        packages = 1
2019/08/03 11:12:45 Info:go/packages.Load
        package = go-module-demo
        files = [/xxx/VscodeProjects/go-module-demo/lib.go /xxx/VscodeProjects/go-module-demo/main.go]

Some output of gopls:

[Error - 11:19:03 AM] Request textDocument/definition failed.
  Message: no object for ident LibStruct
  Code: 0 
[Trace - 11:19:03 AM] Received response 'textDocument/codeAction - (16)' in 0ms.
Params: [{"title":"Organize Imports","kind":"source.organizeImports","edit":{"changes":{"file:///xxx/VscodeProjects/go-module-demo/main.go":[]}}}]


[Trace - 11:19:03 AM] Sending notification 'textDocument/codeAction' in 1ms.
Params: {"textDocument":{"uri":"file:///xxx/VscodeProjects/go-module-demo/main.go"},"range":{"start":{"line":5,"character":12},"end":{"line":5,"character":12}},"context":{"diagnostics":[{"range":{"start":{"line":5,"character":6},"end":{"line":5,"character":17}},"message":"undeclared name: LibStruct","severity":1,"source":"LSP"}]}}

[stamblerre]

@jeffzhangme: Looks like the check command worked correctly. How are you opening VSCode? Make sure to open the directory with the go.mod file (see golang/go#32394), not just the main.go file individually.

[jeffzhangme]

@stamblerre: Thank you very much, it looks normal by opening a go module project directly.
In the past I usually opened a go path directory and add project to subdirectory src.
I tried multiple modules with workspace, but it didn't work very well. Whether there are plans to support multiple modules or maybe this way is the best practice?

[stamblerre]

We do intend to improve this user experience, but we aren't yet sure what form it will take. You can follow along for updates on golang/go#32394.

[jeffzhangme]

OK, thanks again!

[ramya-rao-a]

Closing in favor of the upstream issue