blank *.go files break gopls

[cornfeedhobo]

What version of Go, VS Code & VS Code Go extension are you using?

• Run go version to get version of Go
  • go version go1.12.12 linux/amd64
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders
  • 1.42.1 c47d83b293181d9be64f27ff093689e8e7aed054 x64
• Check your installed extensions to get the version of the VS Code Go extension
  • ms-vscode.go-0.13.0
• Run go env GOOS GOARCH to get the operating system and processor arhcitecture details
  • linux amd64

Share the Go related settings you have added/edited

    "go.useLanguageServer": true,
    "go.lintTool": "golangci-lint",
    "go.lintFlags": [
        "--fast",
    ],

Describe the bug

gopls stops all meaningful output when a *.go file is created that does not have a package ... header.

Steps to reproduce the behavior:

1. Create a new main.go

package main

import "fmt"

func main() {
	fmt.Println("Hello World!")
}

2. Create a blank file

touch foobar.go

3. Start vscode

code .

4. Output -> gopls will display errors
5. Problems will display errors looking for imports

Bonus steps:
5. echo 'package main' > foobar.go
6. Edit any of the go files and see that gopls remains "broken"
7. restart vscode
8. Verify gopls is working as expected again

[hyangah]

@cornfeedhobo thanks for the report. Unfortunately I couldn't reproduce it myself so more info about your set up will be helpful in triaging the issue

• What is the version of gopls you are using?
• Are you using GOPATH mode or modules mode?
• Is it reproducible if go.lintTool is disabled?
• Can you capture and share the error message of gopls? And if possible, please add the following setting to make gopls more verbose for debugging

"go.languageServerFlags": [
    "-rpc.trace", // for more detailed debug logging
    "serve",
    "--debug=localhost:6060", // to investigate memory usage, see profiles
],

thanks!!

[stamblerre]

@cornfeedhobo: Are you using Go 1.13? This is a known issue that is fixed in 1.14. Unfortunately, there's nothing we can do to work-around it until users upgrade to 1.14. The best solution would be to add a package declaration to that file and and save.

[hyangah]

Thanks a lot @stamblerre. @cornfeedhobo is using 1.12. 1.14 will be out this week. Please give it a try.

[stamblerre]

Makes sense. I'm going to close this issue, since it is a known issue with a solution for later versions of Go. Thank you for the report, @cornfeedhobo! For reference, there is an upstream issue tracking this more generally: golang/go#36960.

[cornfeedhobo]

@stamblerre Thanks for the info. Correct, as @hyangah said, I'm using 1.12, which is the highest that SuSE currently packages. I might switch to a newer go version with goenv, but I'm running into larger vscode issues there, which are finally being discussed in another issue.

Thanks again for all the hard work everyone!