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

go/build: symlinks named *.go that refer to directories should not be treated as source files #39841

Open
fishy opened this issue Jun 24, 2020 · 4 comments
Assignees
Labels
Milestone

Comments

@fishy
Copy link

@fishy fishy commented Jun 24, 2020

What version of Go are you using (go version)?

$ go version
go version go1.14.4 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/fishy/.cache/go-build"
GOENV="/home/fishy/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/fishy/.gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build661038676=/tmp/go-build -gno-record-gcc-switches"

What did you do?

This is the minimal sequence of commands to reproduce the issue:

fishy@muto:~/work/tmp$ ls
main.go
fishy@muto:~/work/tmp$ cat main.go
package main

import "fmt"

func main() {
        fmt.Println("vim-go")
}
fishy@muto:~/work/tmp$ go test
?       _/home/fishy/work/tmp   [no test files]
fishy@muto:~/work/tmp$ mkdir foo.go
fishy@muto:~/work/tmp$ go test
?       _/home/fishy/work/tmp   [no test files]
fishy@muto:~/work/tmp$ ln -s foo.go bar.go
fishy@muto:~/work/tmp$ go test
can't load package: package .: read /home/fishy/work/tmp/bar.go: read /home/fishy/work/tmp/bar.go: is a directory
fishy@muto:~/work/tmp$ ls -l
total 8
lrwxrwxrwx 1 fishy fishy    6 Jun 24 16:32 bar.go -> foo.go
drwxr-xr-x 2 fishy fishy 4096 Jun 24 16:32 foo.go
-rw-r--r-- 1 fishy fishy   67 Jun 24 16:32 main.go

What did you expect to see?

go toolchain should ignore bar.go as it's a symlink to a directory, similar to how they ignored foo.go before.

What did you see instead?

go toolchain throws error.

@fishy
Copy link
Author

@fishy fishy commented Jun 24, 2020

Additional note: This is a problem when we use Bazel with Go. When using Bazel it auto creates bazel-<current-dir-name> symlink, and we have a project with ".go" suffix in its name (https://github.com/reddit/baseplate.go) so if we use default git clone directory name, bazel will create bazel-baseplate.go symlink, which will cause errors with the go command. Some of those errors are harmless but some do cause problems, so we have to rename clone it to work around this issue.

@cagedmantis cagedmantis changed the title Go command isn't handling symlinks to directories named as *.go correctly cmd/go: go command isn't handling symlinks to directories named as *.go correctly Jun 25, 2020
@bcmills bcmills added the NeedsFix label Jun 26, 2020
@bcmills bcmills self-assigned this Jun 26, 2020
@bcmills bcmills added this to the Go1.16 milestone Jun 26, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Jun 26, 2020

Change https://golang.org/cl/240120 mentions this issue: go/build: ignore symlinks to directories when matching source files

@bcmills
Copy link
Member

@bcmills bcmills commented Jun 26, 2020

Turns out to be a very simple fix. This does not appear to be a regression in 1.14; I'm not sure whether it should go into 1.15 (since we're deep into the code freeze) or wait for 1.16.

@bcmills bcmills changed the title cmd/go: go command isn't handling symlinks to directories named as *.go correctly go/build: symlinks named *.go that refer to directories should not be treated as source files Jun 26, 2020
@fishy
Copy link
Author

@fishy fishy commented Jun 26, 2020

Yeah this is certainly not a regression. It's probably broken since day 1. Thanks for the fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.