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.

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.

@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.

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

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.

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.

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

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

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

Thank you! Sent you a comment on the CL.

Duplicate of #31553