cmd/go: clarify the implication when module name is 'main'

[hyangah]

go version 1.16

Consider a case where go.mod has module path main, and the top-level package is a non-main package.
A module's path is the prefix for package paths within the module [ref], so the following behavior may not be too surprising. But the behavior difference between go build and go test was surprising.

--- go.mod ---
module main

go 1.16

--- w.go ---
package w

func F() {}

--- w_test.go ---
package w

import "testing"

func TestF(t *testing.T) {
        t.Error("error")
}

$ tree
.
├── go.mod
├── w.go
└── w_test.go
$ go build
$ go test
# main.test
/var/folders/bw/6r6k9d113sv1_vvzk_1kfxbm001py5/T/go-build2194496096/b001/_testmain.go:13:2: cannot import "main"
FAIL    main [build failed]

[jayconrod]

It looks like this is being reported by the compiler. I didn't expect this to be an error since the package name is not main, but I guess that name is reserved.

We should document this and emit a better error message.

[yunnian]

Because I wanted to fix this problem, I studied this case. I found that you have to enter this directory to execute test to cause this problem. For example

issue_dir/
     - go.mod
     - w.go
     - w_ test.go

cd issue_ Dir & & go test // triggers this problem
go test ./issue_dir //does not trigger this problem

I also print out the parameters of go test calling compile：

        "/Users/wuzhenyu/data/go/go_source/pkg/tool/darwin_amd64/compile",
        "-o",
        "/var/folders/0n/bh1syqn51snbht1cjs2hd7cc0000gn/T/go-build2401188547/b001/_pkg_.a",
        "-trimpath",
        "/var/folders/0n/bh1syqn51snbht1cjs2hd7cc0000gn/T/go-build2401188547/b001=>",
        "-p",
        "main",
        "-complete",
        "-buildid",
        "Cx8w0XTpOnm53_g-gNtr/Cx8w0XTpOnm53_g-gNtr",
        "-dwarf=false",
        "-importcfg",
        "/var/folders/0n/bh1syqn51snbht1cjs2hd7cc0000gn/T/go-build2401188547/b001/importcfg",
        "-pack",
        "-c=4",
        "/var/folders/0n/bh1syqn51snbht1cjs2hd7cc0000gn/T/go-build2401188547/b001/_testmain.go",

the error is /var/folders/0n/bh1syqn51snbht1cjs2hd7cc0000gn/T/go-build3028953223/b001/_testmain.go:13:2: cannot import "main"

so open _testmain.go ,have a look :

// Code generated by 'go test'. DO NOT EDIT.

package main

import (
	"os"

	"testing"
	"testing/internal/testdeps"


	_test "main"

)

var tests = []testing.InternalTest{

	{"TestF", _test.TestF},

}

var benchmarks = []testing.InternalBenchmark{

}

var examples = []testing.InternalExample{

}

func init() {
	testdeps.ImportPath = "main"
}

func main() {

	m := testing.MainStart(testdeps.TestDeps{}, tests, benchmarks, examples)

	os.Exit(m.Run())

}

First , Is it fixed to make test run successfully or something? If so, how do you think I should repair it @jayconrod

[jayconrod]

@yunnian Change the module path in go.mod to something other than main. Module paths and versions has a list of restrictions on valid module paths.

[yunnian]

@yunnian Change the module path in go.mod to something other than main. Module paths and versions has a list of restrictions on valid module paths.

I know that changing go mod will work, so this problem does not need to be fixed?

[jayconrod]

@yunnian I think we need to improve the error message and documentation, but the failure here isn't a bug.

Paths that don't contain a dot in the first (or only) path element are reserved. Packages with those paths may be added to the standard library (like embed was in 1.16). Those paths may also have special meaning like all and cmd.

#37641 is a related, accepted proposal. It's safe to have module paths start with test/ or example/.