x/tools/go/internal/gcimporter: position filename inconsistency for os/signal/internal/pty

[mdempsky]

In CL 292351, I added a test to compare cmd/compile's export data output against gcimporter.IExportData. Because cmd/compile generates paths prefixed with "$GOROOT" whereas go/loader generates them with the actual build.Context.GOROOT value, I included code to expand $GOROOT.

However, this turned out to break on the macOS machines, because for package os/signal/internal/pty (and only that package!) go/loader was using "/var/folders/..." but cmd/compile's expanded path became "/private/var/folders/...". The former is a symlink to the latter, so I submitted CL 292910 to workaround this special case.

But the toothrot builder is still unhappy (https://build.golang.org/?repo=golang.org%2fx%2ftools), now because of "/private/tmp" vs "/tmp" (and again, only for os/signal/internal/pty): https://build.golang.org/log/d0edf17481286f622c2764cf38ab1831375ccb94

I don't think the "/private" vs no-"/private" discrepancy is a big deal. They're semantically equivalent paths. But it's bizarre that os/signal/internal/pty is the only package affected by this.

One suspicion: I think os/signal/internal/pty is the only "internal" package that uses cgo?

/cc @findleyr @stamblerre

[toothrot]

/cc @griesemer as well as per dev.golang.org/owners

[gopherbot]

Change https://golang.org/cl/293249 mentions this issue: go/internal/gcimporter: reference golang/go#44339 in TODO

[mdempsky]

I can reproduce the failure on Linux. All you need to do is (from within the x/tools checkout):

ln -s $(go env GOROOT) /tmp/fake-goroot
GOROOT=/tmp/fake-goroot go test -run IExportData_stdlib ./go/internal/gcimporter

[mdempsky]

I think it's go/loader that's being inconsistent here. It uses /tmp/fake-goroot-prefixed paths for all of the declared objects, except for in os/signal/internal/pty.

[mdempsky]

The internal path is a red herring. It's actually that os/signal/internal/pty is the only package to have exported declarations in a file that uses import "C".

When the file is rewritten by cgo, cgo is invoked from the source directory and uses the actual path in //line directives, instead of the symlink-based path that go/loader uses for everything else.

[bcmills]

cgo is invoked from the source directory and uses the actual path

That probably points to a PWD issue somewhere in cmd/go or cmd/cgo (compare #43862).

[gopherbot]

Change https://golang.org/cl/293250 mentions this issue: go/internal/cgo: set pkgdir with -srcdir instead of CWD