Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

documentation: status of relative filenames in line directives unclear #26207

Open
zombiezen opened this issue Jul 3, 2018 · 7 comments

Comments

@zombiezen
Copy link
Contributor

commented Jul 3, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2018

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

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Jul 3, 2018

@zombiezen

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 26, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.