I'm trying to fix and test some issues around cmd/cover and line numbers, but I've run into two compiler problems with the processing of //line directives. These seem like they should be easy fixes.

Literal $GOROOT

g=$(go env GOROOT)
cd $g
echo "//line $g/file:1" >x.go
cat x.go
go tool compile x.go

This creates a trivial x.go with a line directive that gives a full path to a non-existent file in the GOROOT root. (The fact that the file does not exist is irrelevant.)

Then the compiler prints an error because there is no package statement in the file. The error should be reported to the fake file name, and it is, except the path name literally says $GOROOT instead of the actual GOROOT directory.

% go tool compile x.go
$GOROOT/file:1[x.go:2:1]: syntax error: package statement must be first
%

The $GOROOT appears because that's what we do want to write as the file name in the object file and export data. But for error messages we want to see the actual path name. It looks like objabi.AbsFile is being called incorrectly (a bit too early) while handling the //line directive. It looks like the code needs to distinguish between computing PosBase.filename and PosBase.absFilename, and it makes no such distinction.

Line number stack

The syntax $line[$actualLine] in error messages traces back to the Plan 9 C compiler, but it is problematic for code generated during a build because the bracketed path is useless noise. We should turn it off by default. If we want to preserve the ability to see those annotations, we can reintroduce the old -L (show full file names) flag to add this.

For example, the error in the case above needs to say just:

/Users/rsc/go/file:1: syntax error: package statement must be first

without the [x.go:2:1].