Thanks for the report. This functionality comes from staticcheck. Can you please open an issue in the staticcheck issue tracker, and once fixed, we can update gopls's dependency. cc @dominikh

@hyangah Are we sure this isn't an issue with how gopls applies edits?

For the code in the OP, Staticcheck emits 6 code edits. The first 5 replace if <cond> { with case <cond>: and delete the closing } of the block. The sixth edit inserts switch <x> {\n in front of the first if keyword. I admit that this order of edits is non-trivial, but IMO it should work fine, assuming correct tracking of how positions change due to insertions and deletions.

The go/analysis docs do say that

Diagnostics should not contain SuggestedFixes that overlap.

but I'm not sure that replace 0..10 with text and insert text at 0 can be considered to be overlapping.

Thanks @dominikh

@findleyr @adonovan Can you please take a look whether the quick fix translation gopls is doing is sane?
EDIT: I could reproduce it I cannot reproduce it any more. :-(

@tttoad You said you already found an issue in honnef.co/go/tools. Can you share the PR you have?

package foo

import "fmt"

func fn() {
	x := 0
	if x == 1 || x == 2 {
	} else if x == 3 {
		fmt.Println(x)
	} else {
		fmt.Println(x)
	}
}

@hyangah the proposed PR is dominikh/go-tools#1466 — it merges the first and last edit into one.

@dominikh for LSP edits it looks like inserts must precede replace edits, when all start at the same position: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textEditArray.

We're naively translating go/analysis edits to LSP edits, and so that could explain the breakage.

Probably we should keep the edit semantics for go/analysis aligned with LSP, and so should clarify the go/analysis documentation for this case.

@findleyr can you test if dominikh/go-tools@4136a84 fixes the issue? This should respect the order required by the spec.

@hyangah dominikh/go-tools#1466. It works on my mac.

@findleyr @hyangah Any progress on the issue?

@tttoad thanks for testing -- I haven't yet had an opportunity to test for myself.

@tttoad what progress are you expecting? I think the correct path forward is to update staticcheck. This will take some time.

There are currently two competing fixes for the issue in Staticcheck. @tttoad's PR, that combines some of the edits, and my change that attempts to fix the issue by reordering edits.

I'm waiting to hear if my change fixes the issue before merging it to master (or before merging tttoad's PR.)

@dominikh thanks for clarifying.

It will likely take a few days before I can confirm. But I will do so.

@adonovan should we update the go/analysis documentation?

LSP ... inserts must precede replace edits, when all start at the same position
We're naively translating go/analysis edits to LSP edits, and so that could explain the breakage.
Probably we should keep the edit semantics for go/analysis aligned with LSP, and so should clarify the go/analysis documentation for this case.

That new requirement would represent a breaking change to the analysis API. The analysis API's specification is clear enough; let's just take more care in the logic that translates edits to LSP.

(Why does the LSP have that restriction? There's an unambiguous interpretation of any list of non-overlapping edits.)

There are at least a dozen places in gopls that loop over TextEdits, typically converting one form to another (e.g. protocol, analysis, gob). In many cases it's locally obvious that the edits are already ordered (e.g. because they came directly from diff.Strings), but it seems like a thorough audit is necessary. I think source.ApplyFix is the most obvious place where the invariant needs to be considered (and perhaps also lsp.refactorRewrite).

It would be nice if we could simplify those (at least a dozen) loops at the same time, and perhaps eliminate some of the conversions.

Sorry it took so long, but I tested dominikh/go-tools@4136a84 and confirmed that it fixes the issue. (the resulting code is not gofmt'ed, but that's OK).

Alright, thanks for confirming. I've pushed a version of that commit to Staticcheck's master, or you can cherry-pick the old version of that commit on top of the latest release (or you can wait until the next Staticcheck release, of course.)

Thanks. I think we'll wait for the next staticcheck release, as this has existed for a while.
(EDIT: milestoning for v0.16.0 (N+2), as a reminder to update staticcheck and add a test).