and my final go binnary can successfully run and build allman style go files,
it seems that everything is OK,
but I don’t know what’s the usage of the file: github/forkgo-org/go/blob/master/src/go/scanner/scanner.go#L864
and I can’t figure out how to modify it to keep it consistent with: github/forkgo-org/go/blob/master/src/cmd/compile/internal/syntax/scanner.go#L119
Why are there 2 scanner.go files? Can we merge them into one?
Sorry for forking golang go, blame me softly please.
Welcolm to help me fix the github/forkgo-org/go/blob/master/src/go/scanner/scanner.go#L864
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 as go/parser and go/types,
have no relation to the compiler. Since the compiler was initially written in C,
the go/* packages were developed to enable writing tools working with Go code,
such as gofmt and vet.
… 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?