cmd/go: clarify the implication when module name is 'main' #45194
Comments
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 We should document this and emit a better error message. |
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
I also print out the parameters of go test calling compile:
the error is so open
First , Is it fixed to make test run successfully or something? If so, how do you think I should repair it @jayconrod |
@yunnian Change the module path in |
I know that changing go mod will work, so this problem does not need to be fixed? |
@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 #37641 is a related, accepted proposal. It's safe to have module paths start with |
go version 1.16
Consider a case where
go.mod
has module pathmain
, 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
andgo test
was surprising.The text was updated successfully, but these errors were encountered: