x/tools/gopls: improve diagnostics for empty go files

[hyangah]

I propose not to generate diagnostics for the newly created, empty file.

Assume this user workflow:

• mkdir hello; cd hello
• run go mod init example.com/hello
• open the folder from an editor (e.g. vscode with gopls enabled by default)
• create a new file hello.go, using the editor's feature

The first thing the user will notice is a diagnostic error message.

[Trace - 17:35:12.131 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///Users/hakim/hello/hello.go","diagnostics":[{"range":{"start":{"line":0,"character":0},"end":{"line":0,"character":0}},"severity":1,"source":"syntax","message":"expected ';', found 'EOF'"}]}

It's not a critical, major issue, but it's not nice nor useful to present an error message before the user starts typing anything.

[stamblerre]

On one hand, I agree that the error message is not useful for beginners. But on the other hand, it feels like it's the responsibility of gopls to show the errors that the compiler would report for a given file.

Maybe we could modify the error message to be more helpful?

[hyangah]

The message expected ';', found 'EOF' is definitely not very user-friendly - especially go is known for a language that doesn't require ;. But what will be the alternative error message? For existing empty files, marking this as an error is reasonable. For a newly open file (which gopls knows) though, shouldn't it delay its diagnostic notification before the file is edited?

[stamblerre]

@heschik @findleyr what are your thoughts on this?

[heschi]

I think we should be focusing on the underlying problem we're trying to solve, not the symptoms. If the concern is that creating a new package is not user-friendly, let's talk about what to do about it from the beginning. For example, should we fill a package clause in for new files? Prompt the user somehow?

[stamblerre]

For example, should we fill a package clause in for new files?

We've had a few requests for this behavior in VS Code Go (vim-go does this), but it's not clear to me that it's definitely the best approach. For experienced users, it can be annoying, especially if you want something different than the prefilled package declaration.

[heschi]

Shrug. Then we can try to get the error improved upstream for 1.16, I guess.