It’s interesting that it’s not mentioned. I might suspect it’ll be C, as otherwise they’d need to build a new C parser in Go to even get started. Why not use a mature one, and add the Go transformation?
Edit: to be more precise, they’d need to get the C syntax tree in some representation first. Then pass it over to a transformer. The latter could be in Go, but it seems foolhardy to reinvent the former.
By the time I reached this post, the number of translation tiers managed to confuse me. To help others, here's a breakdown.
Notation: T[A,B] : Translates from A to B
The OP wants to develop T[C, Go]. The question is which language should T[C,Go] be written in?
Option #1: If T[C,Go] is written in C, then it can use an existing C parsing library to parse C and then emit Go. Here parsing will be easier, but emitting Go will be laborious to write in C (since C is very low level).
Option #2: If T[C,Go] is written in Go, then the parent claims that C parsing will have to be freshly developed in Go. This will be a pain but the Go emitting code will be easier to write in Go.
However, I think the problem with option #2 (parsing) can be avoided if one uses the parsing library that is assumed to be already available in C. Since Go can interface with C code[1], the parser need not be reinvented.
Even if written in C, generating source code is trivial compared to parsing. The translator doesn't have to output the prettiest code either, since there's gofmt/fix.
Edit: to be more precise, they’d need to get the C syntax tree in some representation first. Then pass it over to a transformer. The latter could be in Go, but it seems foolhardy to reinvent the former.