I'd rather not tie more information about positions into the syntax package (in fact, I've been trying to see if I can come up with an approach that takes that dependency on the pos package out again). I'm still hoping we can keep this package pretty clean, so that at some point we can expose it outside.

Regarding the issue: What is the actual problem? Is it that we want to the base indices be representative somehow of the order in which files were presented to the compiler?

The motivating issue is I was working on reviewing CL 40095, which has an API like (simplify):

func openScope(start, end src.XPos)
func closeScope()

So this API requires converting the { and } token positions to src.XPos before actually processing the contents within. I.e., it can register PosBases out of order.

This is problematic in practice for cgo, because it very heavily uses //line annotations. (To paraphrase Obi-Wan, "It's more pragma now, than code.")

I'm leaning towards changing the API to "openScope(start)" and "closeScope(end)" separately, which hopefully avoids the issue, but I worry there could still be other places where we Pos->XPos transform out of order.

Discussed with @griesemer: not important for Go 1.9 (we can workaround it), but something to think about for 1.10.