8f0cc6 breaks internal imports across repo boundaries

[Dan Kortschak]

In the gonum project we have a github.com/gonum/internal repository that
holds shared internal code used by other repositories in the project.
From my reading of the internal packages proposal there should be no
problem doing this; there is no indication of the notion of a repository
in the proposal, just paths.

```
An import of a path containing the element “internal” is disallowed if
the importing code is outside the tree rooted at the parent of the
“internal” directory.
```

However, we are now seeing failures on tip with e.g. the following set
up:

floats "github.com/gonum/floats" imports asm:

import "github.com/gonum/internal/asm"


The failure does not appear to be by design however:

$ go get -t -v ./...
github.com/gonum/floats (download)
panic: runtime error: slice bounds out of range
goroutine 1 [running]:
main.disallowInternal(0xc2084432f0, 0x2f, 0xc208454800, 0xc2080ebb60,
0x2)
/home/travis/.gimme/versions/go/src/cmd/go/pkg.go:345 +0x487
main.loadImport(0xc208441941, 0x1d, 0xc2084432f0, 0x2f, 0xc2080ebb60,
0xc208443890, 0x1, 0x1, 0x0)
/home/travis/.gimme/versions/go/src/cmd/go/pkg.go:285 +0x863
main.(*Package).load(0xc208454000, 0xc2080ebb60, 0xc208177800, 0x0, 0x0,
0x4)
/home/travis/.gimme/versions/go/src/cmd/go/pkg.go:620 +0x413c
main.loadImport(0xc20815db41, 0x17, 0xc208010144, 0x2d, 0xc2080ebb60,
0x0, 0x0, 0x0, 0x0)
/home/travis/.gimme/versions/go/src/cmd/go/pkg.go:278 +0x6fb
main.loadPackage(0xc20815db41, 0x17, 0xc2080ebb60, 0x0)
/home/travis/.gimme/versions/go/src/cmd/go/pkg.go:902 +0x1398
main.download(0xc20815db41, 0x17, 0xc2080ebb60, 0xc2080eb700)
/home/travis/.gimme/versions/go/src/cmd/go/get.go:222 +0x168d
main.download(0xc208147908, 0x15, 0xc2080ebb60, 0xc20811d901)
/home/travis/.gimme/versions/go/src/cmd/go/get.go:255 +0x911
main.runGet(0xb95aa0, 0xc20800a0e0, 0x1, 0x1)
/home/travis/.gimme/versions/go/src/cmd/go/get.go:79 +0x161
main.main()
/home/travis/.gimme/versions/go/src/cmd/go/main.go:177 +0x750
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/home/travis/.gimme/versions/go/src/runtime/asm_amd64.s:1700 +0x1
goroutine 5 [syscall]:
os/signal.loop()
/home/travis/.gimme/versions/go/src/os/signal/signal_unix.go:22 +0x1f
created by os/signal.init.1
/home/travis/.gimme/versions/go/src/os/signal/signal_unix.go:28 +0x3e

[David Symonds]

That sounds like a bug. I thought there was already a very
similar-sounding issue, but I can't find it. Could you please file
one?

https://golang.org/issue/new

[Dan Kortschak]

https://github.com/golang/go/issues/11055