cmd/go: explicitly reject packages whose source files contain leading dots

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

go1.11.1 darwin/amd64

Does this issue reproduce with the latest release?

Yes, tested with:

go1.12rc1 darwin/amd64

But at least the latest version shows the ._ filename being processed, and generates 'unexpected NUL in input'

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

GOARCH="amd64"
GOBIN="/Users/peter/go/bin"
GOCACHE="/Users/peter/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"

What did you do?

go build

What did you expect to see?

module to build without errors, which it does after deleting the spurious ._<filename>.go file.

Probably the go command line tools should be ignoring these system files.

What did you see instead?

fails with "cannot find package"
I initially thought this was related to #27238 but I think it is a different problem specific to macos. However it might be worth adding a link from there in case anyone else has this problem.

[bcmills]

Any idea how the spurious file was created in the first place?

They are a standard part or macos from what I understand. I normally just add ._* to my .gitignore file. In this case I was not using VCS, since I was testing go module support with a non VCS dependency, i.e. local module using the 'replace' workaround. Hence my confusion with the reported error message.

[bcmills]

We should probably reject .go source files with leading dots entirely.

[bcmills]

CC @jayconrod

[jayconrod]

I wouldn't be surprised if some packages were broken by the removal of dot files. I know at least some repos rely on directories with a dot or underscore prefix for packages that aren't built automatically by go build ./....

Excluding file names with the prefix ._ seems reasonable to me though.

Should these be rejected with an error or ignored? If the OS is creating them automatically for search indexing, ignoring might be the right option.

[bcmills]

Should these be rejected with an error or ignored?

I think we should reject them explicitly, since they likely used to be allowed: better to give an error than to silently compile a package that is missing some of its (possibly-exported) identifiers.

I think if you only ignore the ._ files you'll avoid the issue with .dir or _dir mentioned above.
macos includes a tool to delete these system files: 'dot_clean .' but that would mean having to run that before every build if this was treated as an error, since there is no knowing when the OS might create more.