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

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

Open
hyangah opened this issue Mar 24, 2021 · 5 comments
Open

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

hyangah opened this issue Mar 24, 2021 · 5 comments
Labels
Milestone

Comments

@hyangah
Copy link
Contributor

@hyangah hyangah commented Mar 24, 2021

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]
@hyangah hyangah transferred this issue from golang/vscode-go Mar 24, 2021
@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Mar 24, 2021

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.

@jayconrod jayconrod added the NeedsFix label Mar 24, 2021
@jayconrod jayconrod added this to the Backlog milestone Mar 24, 2021
@yunnian
Copy link

@yunnian yunnian commented Mar 29, 2021

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
Copy link
Contributor

@jayconrod jayconrod commented Mar 29, 2021

@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
Copy link

@yunnian yunnian commented Mar 29, 2021

@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
Copy link
Contributor

@jayconrod jayconrod commented Mar 29, 2021

@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/.

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