cmd/internal/src: XPos.After doesn't necessarily match Pos.After

[mdempsky]

XPos.After (and XPos.Before) compares XPoses with different bases according to their base index, which is determined by the order they're added to the PosTable. I think this is worrying because we don't currently have any code in the compiler to ensure PosBase are registered in order.

Possible solutions I see:

1. Change XPos.After's signature to take a *PosTable parameter and return the result of comparing the corresponding Pos values.
2. Change package syntax's parser to register PosBase with the PosTable during parsing. (Will require locking.)
3. Change package syntax's parser to collect all PosBase into a slice which we can register serially once parsing is done.

/cc @griesemer

[griesemer]

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?

[mdempsky]

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.

[mdempsky]

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