x/tools/gopls: handle formatting on files that do not parse

[stamblerre]

If we don't check a package's parse errors before formatting, we may encounter a case where we delete code on format.

Repro:

package foo

func _() {
	f(),
	f()
}

To handle this, we check the parse errors before formatting. However, we should confirm that these errors belong to the file in question and lie within the specified range before failing.

[myitcv]

@stamblerre @ianthehat - should/can we also use this issue to pick up the conversation from https://go-review.googlesource.com/c/tools/+/171019/2#message-f8bec621217d3d2caad7dda408cdc629c71aaed6:

We should have a discussion about overall approach. The source package needs to return errors, because it has no idea about the environment it is running in, the question is whether the lsp package should log or propagate those errors. We were propagating them because we had no wired up way of logging, but I fixed that recently, so now we could choose to log them instead. We need to decide what level of failure should result in an error vs an empty result (does formatting a non existent file count as an actual error?)

Or do you want to capture that discussion about error propagation elsewhere?

[ianthehat]

I think that is a separate issue. In fact, is now issue #31526

[natefinch]

This is a huge quality of life issue for me, and probably many others. Not being formatted makes it harder to fix errors so that the code can compile. This literally makes it harder and slower for me to code in Go.

[stamblerre]

As a temporary workaround, we could shell out to the gofmt binary when a file has parse errors.

[gopherbot]

Change https://golang.org/cl/187757 mentions this issue: internal/lsp: format files in packages with errors

[gopherbot]

Change https://golang.org/cl/188767 mentions this issue: internal/lsp: format files that parse in packages with parse errors