I realise that this could qualify as "abusing" the syntax tree nodes. However, I don't see why go/printer should ever write incorrect or different code. The only alternative would be to write lots of code to always make sure that the positions are OK, which I'm not sure is possible.

Conceivably, your updated AST is not a valid one. Perhaps you can verify this using one of the AST library predicates/validators?

I'd disagree. Even if you print a syntax tree with an empty fileset, the printer should still print a valid program, even if the style ends up looking weird.

For example, other similar statements like go and defer don't have this same bug, so I think this is simply human error. The fix is also trivial - I'm finishing the test now.

So you are unable to verify whether your generated AST is valid?

Change https://golang.org/cl/184121 mentions this issue: go/printer: never print a newline before the returned results

Sorry, I don't know what you mean. The syntax tree is perfectly valid. The position information obtained via the fileset is a bit weird, but still, I don't think that should lead to the printer producing incorrect output and no error.

I also don't know what validators you're talking about. You can validate the syntax tree example I gave above, if that helps.

@mvdan I agree this is a bug. Unfortunately, the go/printer can produce incorrect formatting in some cases.

I understand these edge cases are super rare, primarily because one needs to craft a syntax tree manually. It's impossible for gofmt to run into this bug, I think. In any case, I'm happy to send patches like this one if you're happy to review them.

@mvdan I can review them but it's not a high priority. The shorter the better, of course :-)