CC @griesemer

Hm, indeed. Looks like a bug at first glance. Thanks for reporting.

Why is this a bug? The gofmt formatting of switch case comments has two valid arrangements, 1) aligned with the leading c of case and 2) indented one level from the case statement.

If the code in the expected section is formatted, it remains the same (this can be tried here). The issue is how gofmt can know which of the two cases the author wants (one would likely be a case-leading comment and the other an in case-block comment as shown here - which remains unchanged when gofmt is run).

I note there is some discussion on this in gophers #tools that would be relevant to bring in here.

The issue from the slack discussion was when you manually moved the comments into alignment with the case (leading c) gofmt would still reformat and indent it one level in. Looking at it now I think the examples included here don't accurately reflect that behavior.

I'm familiar with this gofmt behavior, and I've spent some time thinking whether it's a bug or not (if it is, it's very minor). I agree with @kortschak's characterization of this issue.

Given there are two valid gofmt-ed outcomes, I think gofmt should be making the edit which results in a smaller diff. So, given this non-gofmted block:

for {
	switch n {
	case 1:
		foo()
			// Comment that applies to case 1 or case 2 depending on its indentation.
	case 2:
		bar()
	}
}

After formatting, it should become:

for {
	switch n {
	case 1:
		foo()
		// Comment that applies to case 1 or case 2 depending on its indentation.
	case 2:
		bar()
	}
}

This is the current behavior. I think it's good.

However, the other side doesn't work as expected. Starting with this non-gofmted block:

for {
	switch n {
	case 1:
		foo()
// Comment that applies to case 1 or case 2 depending on its indentation.
	case 2:
		bar()
	}
}

gofmt currently inserts two tabs instead of one tab.

Given both one tab and two tabs would make the program gofmted, I think it should be making the smaller edit rather than the bigger.

Seems like this and similar cases have come up a couple times now, see #30327 and its linked issues.

I guess the issue here is that there is no agreed upon definition on how comments in switch-statements should be inlined, but I agree with the above proposal.

However, a question that would come up is still the comment at the end of the whole switch statement block, as shown in #30327:

package main

func main() {
	val := 1
	switch val {
	case 1:
		_ = 1
	// case 5: // gets aligned to the case <- this would be left as-is, which makes sense.
	// 	_ = 5
	case 2:
		_ = 2
		// case 3: // gets aligned to the code block inside the case <- this would be left-as-is?
		// 	_ = 3
	}
}

While the case 5 comment is clear, I think case 3 should be indented to the same level as the other cases.
The reason for this is that I suspect (I don't have any numbers on this) that comments right before the end of a switch statement are rarely referring to the code above them.

This would be an enhancement to what has been said by @dmitshur, for completeness.

This is a bug (or quirk) that has existed for many years, and it's very minor. It seems too late to work on a fix this late in the 1.15 cycle, so I'll move this to backlog and we can revisit in the future.