Go: x/tools/cmd/goimports: rewrite 0X->0x, 0O->0o as gofmt does
In Go 1.13, gofmt started canonicalizing hex literals written as 0XABC as 0xABC and also started rewriting the newly introduced octal literals written as 0O123 as 0o123. But goimports doesn't do this rewriting. This means that code formatted by goimports may be further altered by gofmt, which I think we've always tried to avoid.
cespare
All 9 comments
Hm. I generally agree, but gofmt is implicitly versioned as part of the Go distribution, whereas goimports is free-floating. So under what circumstances should we do the rewrite? goimports built with 1.13+? go1.13+ in the go directive of a go.mod? Would require more thought.
heschik
on 25 Feb 2020
So under what circumstances should we do the rewrite? goimports built with 1.13+?
Yes, exactly this.
This is already how goimports works today and those of us who care about getting a particular behavior of goimports to match gofmt already know that we need to match the goimports build version of Go with the gofmt Go version.
For instance, in Go 1.11 gofmt changed the alignment of certain literals (see 542ea5ad91367d2b40589942cc5757a4d5f43f97). If I build (tip) goimports with Go 1.10, I get the Go 1.10 gofmt alignment. If I build goimports with Go 1.11, I get the Go 1.11 gofmt alignment.
cespare
on 25 Feb 2020
Maybe...but messing with someone's spacing feels different than preventing their code from compiling. Perhaps if we did it around 1.15 when there'd be some expectation everyone will have support for the new literals.
heschik
on 25 Feb 2020
@heschik I think you're confusing this with a different issue (possibly #33363). I'm not talking about preventing anyone's code from compiling. This is about:
- Changing 0X to 0x, both of which are valid in all versions of Go.
- Changing 0O to 0o, both of which only exist in Go 1.13+.
cespare
on 25 Feb 2020
Oh. Sorry, not paying enough attention. Sure, yes, let's do it. Do you happen to have the gofmt CL handy? Do you want to send a CL?
heschik
on 25 Feb 2020
The original gofmt change was CL 160184.
I can send a goimports CL at some point if nobody beats me to it.
cespare
on 25 Feb 2020
Change https://golang.org/cl/231461 mentions this issue: cmd/gofmt, go/format, go/printer: move number normalization to printer
gopherbot
on 1 May 2020
Change https://golang.org/cl/237740 mentions this issue: doc/go1.15: document go/printer.StdFormat
gopherbot
on 13 Jun 2020
Change https://golang.org/cl/240683 mentions this issue: go/printer: document the StdFormat mode better
gopherbot
on 1 Jul 2020
Related issues
natefinch
路
3Comments
go101
路
3Comments
gopherbot
路
3Comments
lkarlslund
路
3Comments
michaelsafyan
路
3Comments
Most helpful comment
Yes, exactly this.
This is already how goimports works today and those of us who care about getting a particular behavior of goimports to match gofmt already know that we need to match the goimports build version of Go with the gofmt Go version.
For instance, in Go 1.11 gofmt changed the alignment of certain literals (see 542ea5ad91367d2b40589942cc5757a4d5f43f97). If I build (tip) goimports with Go 1.10, I get the Go 1.10 gofmt alignment. If I build goimports with Go 1.11, I get the Go 1.11 gofmt alignment.