runtime: status of relative filenames in //line directives unclear

[zombiezen]

I'd like to be able to specify relative paths in //line directives, but it's unclear whether this is permitted. Experimentally, it seems as though they are not. #3335 and #24183 are both related in terms of trying to specify what's allowed in the directive, but I haven't seen this specific issue mentioned.

(For runtime.Caller info, it seems to expect that the filename is an absolute path.)

What did you do?

$ mkdir foo
$ cat > foo/foo.go
package main

func main() {
    asdf
}
$ cat > foo/bar.go
package main

//line baz.go:1234
func quux() {
    asdf
}
$ go build ./foo

What did you expect to see?

# foo
foo/baz.go:1235:5: undefined: asdf
foo/foo.go:4:5: undefined: asdf

What did you see instead?

# foo
baz.go:1235: undefined: asdf
foo/foo.go:4:5: undefined: asdf

System details

go version go1.10.3 linux/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/light/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/light"
GORACE=""
GOROOT="[redacted]"
GOTMPDIR=""
GOTOOLDIR="[redacted]"
GCCGO="gccgo"
CC="clang"
CXX="[redacted]"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build576788924=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.10.3 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.10.3
uname -sr: [redacted]
/lib/x86_64-linux-gnu/libc.so.6: [redacted]
gdb --version: [redcated]

[ianlancetaylor]

What you say in the //line directive is what you get. If you want foo/bar.go you need to say foo/bar.go.

[zombiezen]

The behavior seems a little unfortunate to me. Not pictured here, but runtime.Caller seems to expect that //line have an absolute path, which would then mean that the whole absolute path would be displayed in the error message. Further, this implies that code generator output would likely differ between checkouts: not ideal if generated code is checked in.

[ianlancetaylor]

Sorry, I guess I don't understand what you mean. runtime.Caller should report exactly what is in the //line directive; does that not happen for you? And I don't see understand the code generator output would change. The code generator should generate the //line directives that it wants.

OK, maybe I do see what you mean. You are saying that the default file paths returned by runtime.Caller are absolute paths. Therefore, tools that look at runtime.Caller output, or, equivalently, stack tracebacks, are expecting absolute paths. If a //line directive has a relative path, it's not clear from what root it should be traced.

So you are requesting some way that a code generator can produce a //line directive that refers to a file in the source tree, via a relative path, that some tool somehow transforms into an absolute path.

[zombiezen]

Your understanding is correct. Apologies for my terseness. Restating slightly, my observation is that without //line directives:

• go build will display the path to a file relative to the working directory go build was run from.
• runtime.Caller will return an absolute path to the file, unless a flag like -trimpath is used.

With a //line directive, I observe:

• go build will print exactly the filename in the //line directive.
• runtime.Caller will return exactly the filename in the //line directive. (I haven't tried combining this with -trimprefix.)

I don't see a way to place a filename in a //line directive that will match the behavior of the default case, since the default behavior prints two different strings.

If you'd like, I can open up a separate feature request for changing the //line behavior. But first, it seemed like the behavior was unspecified, so I wanted to understand whether I was missing something or there was behavior that was being depended on.

[ianlancetaylor]

I think the current behavior is specified. The docs say "A line directive specifies the source position for the character immediately following the comment as having come from the specified file, line and column." I think you are asking for a way to specify a relative path that the compiler will change to an absolute path, rather than simply using "the specified file."

[zombiezen]

I am asking for that, but even in the absolute path case, go build will report the full absolute path specified in the directive instead of relative to the directory go build was invoked from. go build treats it differently.

[zombiezen]

FWIW, golang.org/cl/100235 seems related to this ambiguity.