Use gofumpt to format code

[kolyshkin]

gofumpt (https://mvdan.cc/gofumpt) is a fork of gofmt with stricter rules.

Brought to you by

git ls-files \*.go | grep -v ^vendor/ | xargs gofumpt -s -w

Looking at the diff, all these changes make sense.

Also, replace gofmt with gofumpt in golangci.yml.

[kolyshkin]

Perhaps we can squeeze this and #2974 in before 1.0?

[mrunalp]

Can gofmt pass after gofumpt? If so, can we run both? If gofumpt doesn't get updated in the future, then we can fall back to gofmt.

[kolyshkin]

Can gofmt pass after gofumpt?

Yes it can. gofumpt is a superset.

If so, can we run both?

Does not make sense to me, as they are 99% similar and gofumpt is doing its job. Frankly, gofmt is somewhat abandoned, see e.g. golang/go#6996.

If gofumpt doesn't get updated in the future.

Oh, you mean to sort of re-check gofumpt results with gofmt. For that, we need to run gofumpt first in "fixing" mode, then run gofmt on top of it, which is a separate job.

golangci-lint runs all checkers in parallel, and so if we just add both gofumpt and gofmt, we'll end up double amount of linter warnings.

Now, I hope that we should trust @mvdan's good track record and rely on his promise of "running gofmt after gofumpt should be a no-op".

[kolyshkin]

TL;DR: we don't want both gofumpt and gofmt as it will just double the amount of linter warnings.

[mvdan]

Right, gofumpt output is designed to be a strict subset of gofmt output. If you see gofmt changing a program after gofumpt ran on it, or if gofumpt itself isn't stable when run twice in a row, that's a bug. There have been a few of those over the years, but they should be rare and relatively easy to fix when reported.

[kolyshkin]

Tentatively set 1.0.0 milestone as this seems like a good fit.

[cyphar]

LGTM. It is interesting that so many of these were allowed.