x/tools/gopls: declarations are not picked from new files

[anjmao]

What version of Go are you using (go version)?

go version go1.12.6 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/anjmao/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/anjmao/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/anjmao/s/hello/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/jc/q8b4yjwd5dvgc42xpg6yvm8c0000gn/T/go-build972815364=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

1. In VSCode create main.go

main.go

package main

func main() {

}

2. Add another file foo.go. It is important that you type it instead of copying. In most cases if I just copy and save it works.

foo.go

package main

func foo() {}

3. Now try to use foo function inside main.

main.go

package main

func main() {
    foo()
}

What did you expect to see?

I expect to get completion for foo inside main.go

What did you see instead?

I do not get completion, instead I get error undeclared name: foo

Gopls starts to recognise foo only If a do more edits inside foo.go. Also If I delete foo.go in main.go I see no errors.

[gopherbot]

Thank you for filing a gopls issue! Please take a look at the Troubleshooting section of the gopls Wiki page, and make sure that you have provided all of the relevant information here.

[stamblerre]

Thanks for filing this issue! I'm able to reproduce it.

I think we will need to re-run packages.Load if we detect a new file has been created, though I'm not sure how we will handle that considering we only see this as a textDocument/didOpen call. I'll investigate this further.

[anjmao]

@stamblerre I saw in lsp spec there is workspace/didChangeWatchedFiles event which also contains file change type

interface DidChangeWatchedFilesParams {
	/**
	 * The actual file events.
	 */
	changes: FileEvent[];
}

interface FileEvent {
	/**
	 * The file's URI.
	 */
	uri: DocumentUri;
	/**
	 * The change type.
	 */
	type: number;
}

export namespace FileChangeType {
	/**
	 * The file got created.
	 */
	export const Created = 1;
	/**
	 * The file got changed.
	 */
	export const Changed = 2;
	/**
	 * The file got deleted.
	 */
	export const Deleted = 3;
}

This make sense as you can remove or add whole folder with bunch of files.

[anjmao]

@stamblerre Hi, could you also add this to v1.0 milestone? Thanks.

[ctxkenb]

I see there's different behaviour depending on whether modules have been initialized. If I do mod init first, I see completion for 'foo' in main.go. If I don't do mod init, i can reproduce.

[stamblerre]

The reason for this is that, when you are outside of GOPATH and have not initialized a module, the go command treats your package as an "ad-hoc" package. That is, we can make some basic guesses about your code, but go list will report each file in the directory as a separate package.

Perhaps we can add some more work-arounds in go/packages to mitigate this behavior.

[gopherbot]

Change https://golang.org/cl/202277 mentions this issue: internal/lsp: make gopls work for multi-file non-module packages

[ctxkenb]

CL above tries to solve it by modifying internal/lsp instead of go/packages.

[ctxkenb]

I've updated the CL to fix this in go/packages

[stamblerre]

Thank you! Sent you a comment on the CL.

[stamblerre]

Duplicate of #31553