Your fork goes against what I think is one of the core tenets of go, which is that it is opinionated about formatting. The reason go is opinionated about formatting is to avoid things like this where teams argue about Allman vs K&R. I’ve participated in those debates on teams in the past, and it’s always a waste of time. So, you’re probably not going to find a lot of support I would wager.
Also, if you’re modifying a compiler and don’t understand the code you’re modifying, that seems like a bad idea to me. A quick glance at the packages in question revealed this comment in the introduction to the compiler:
Note that the
go/*family of packages, such asgo/parserandgo/types,
have no relation to the compiler. Since the compiler was initially written in C,
thego/*packages were developed to enable writing tools working with Go code,
such asgofmtandvet.
… which explains why there are two implementations. go/* was built to enable tooling written in go, with no relation to the compiler.
You’re going to run in to major problems working on a team after you get your fork working. My editor, for example, runs go fmt on my files when I save them. If your team / collaborators aren’t running on your fork, every time they save it will overwrite the format on your file. Is this just a learning exercise / pet project?