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

test: fixedbugs/issue15609.go and fixedbugs/issue29612.go failing on master #33912

Closed
mvdan opened this issue Aug 28, 2019 · 18 comments
Closed
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done. Testing An issue that has been verified to require only test changes, not just a test failure.
Milestone

Comments

@mvdan
Copy link
Member

mvdan commented Aug 28, 2019

$ go version
go version devel +372b0eed17 Wed Aug 28 12:57:59 2019 +0000 linux/amd64
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/mvdan/go/bin"
GOCACHE="/home/mvdan/go/cache"
GOENV="/home/mvdan/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY="brank.as/*"
GONOSUMDB="brank.as/*"
GOOS="linux"
GOPATH="/home/mvdan/go"
GOPRIVATE="brank.as/*"
GOPROXY="https://proxy.golang.org"
GOROOT="/home/mvdan/tip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/mvdan/tip/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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-build921353500=/tmp/go-build -gno-record-gcc-switches"
$ cd test
$ go run run.go
# go run run.go -- fixedbugs/issue15609.go
exit status 1
go: cannot find main module; see 'go help modules'

FAIL    fixedbugs/issue15609.go 0.043s
# go run run.go -- fixedbugs/issue29612.go
exit status 1
go: cannot find main module; see 'go help modules'

FAIL    fixedbugs/issue29612.go 0.031s

/cc @bcmills @jayconrod

@mvdan mvdan added modules NeedsFix The path to resolution is known, but the work has not been done. Testing An issue that has been verified to require only test changes, not just a test failure. labels Aug 28, 2019
@mvdan
Copy link
Member Author

mvdan commented Aug 28, 2019

The longtest builder seems happy with them, so this is probably something about my environment. Perhaps my setting of GO111MODULE=on or another one of the env vars.

@mvdan
Copy link
Member Author

mvdan commented Aug 28, 2019

Yup, that guess was right. I can send a fix.

@mvdan mvdan self-assigned this Aug 28, 2019
@bcmills
Copy link
Contributor

bcmills commented Aug 28, 2019

Thanks. Could've sworn that I fixed fixedbugs in #30228, but perhaps I missed the go run mode of operation, or perhaps it has regressed since the switch back to auto.

@mvdan
Copy link
Member Author

mvdan commented Aug 28, 2019

Or perhaps it involves other pieces of my env. I'll investigate a bit more.

@bcmills
Copy link
Contributor

bcmills commented Aug 28, 2019

It may be that I only fixed it when run via cmd/dist and not with go run directly.

@bcmills
Copy link
Contributor

bcmills commented Aug 28, 2019

Ah, perhaps it regressed at the same time as #33890?

@bcmills bcmills added this to the Go1.14 milestone Aug 28, 2019
@mvdan
Copy link
Member Author

mvdan commented Aug 28, 2019

Hmm, these dirs have no go.mod, and the error is different, so I don't think it's the same issue. But it could be related.

@bcmills
Copy link
Contributor

bcmills commented Aug 28, 2019

Ah, if the test is running a go command inside a directory, we may need to follow the model of CL 165498 and add a go.mod file in that directory.

@mvdan mvdan removed their assignment Aug 28, 2019
@bcmills bcmills self-assigned this Aug 28, 2019
@cuonglm
Copy link
Member

cuonglm commented Aug 28, 2019

@mvdan I have the same issue with go test cmd/vet, it's failed if GO111MODULE=on. I always to run:

env -u GO111MODULE go tool dist test

@mvdan
Copy link
Member Author

mvdan commented Aug 28, 2019

Hmm, go test cmd succeeded for me just a short while ago. If you still encounter issues, please file a bug.

@cuonglm
Copy link
Member

cuonglm commented Aug 28, 2019

@mvdan I did, see #32107

@bcmills bcmills added the early-in-cycle A change that should be done early in the 3 month dev cycle. label Aug 28, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@katiehockman
Copy link
Contributor

This issue is still happening. I just ran ./all.bash and got the following failure:

##### ../test
# go run run.go -- fixedbugs/issue15609.go
exit status 1
go: cannot find main module; see 'go help modules'

FAIL	fixedbugs/issue15609.go	0.043s
# go run run.go -- fixedbugs/issue29612.go
exit status 1
go: cannot find main module; see 'go help modules'

FAIL	fixedbugs/issue29612.go	0.036s
2020/03/23 10:30:53 Failed: exit status 1

@bcmills should we be adding a go.mod like you said?

@bcmills
Copy link
Contributor

bcmills commented Mar 23, 2020

Looks like this regressed in CL 177798 (CC @cuonglm, @ianlancetaylor, @bradfitz), which was committed shortly after the test fixes for #30228 went in.

The runindir command added in that CL and its tests will need to be reworked: at least one of the directories it runs uses a relative import, which is not allowed in module mode.

@cuonglm
Copy link
Member

cuonglm commented Mar 24, 2020

Looks like this regressed in CL 177798 (CC @cuonglm, @ianlancetaylor, @bradfitz), which was committed shortly after the test fixes for #30228 went in.

The runindir command added in that CL and its tests will need to be reworked: at least one of the directories it runs uses a relative import, which is not allowed in module mode.

I can't reproduce this at tip.

This at least will failed if you set GO111MODULE=on, with off, auto or GO111MODULE unset, it runs ok.

@bcmills
Copy link
Contributor

bcmills commented Mar 24, 2020

This at least will failed if you set GO111MODULE=on

Yes, that's the problem: all of the tests in the go repo should pass regardless of the vaule of GO111MODULE.

@cuonglm
Copy link
Member

cuonglm commented Mar 24, 2020

This at least will failed if you set GO111MODULE=on

Yes, that's the problem: all of the tests in the go repo should pass regardless of the vaule of GO111MODULE.

Can we just explicitly set GO111MODULE=off for runindir, or maybe for the entire test? Those tests should not be affect by go modules IMHO.

@bcmills
Copy link
Contributor

bcmills commented Mar 24, 2020

Can we just explicitly set GO111MODULE=off for runindir, or maybe for the entire test?

We could, but then those tests would break if (likely when) GO111MODULE=off goes away at some point. I don't think we should take on that kind of technical debt, especially given the large effort I've already put into making all of the other tests in the repo work seamlessly in both modes.

I don't mind adding GO111MODULE=off for tests of explicitly GOPATH-specific behavior (such as GOPATH-mode support in the go/build package), but none of the behaviors that these tests are looking for are specific to GOPATH mode.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/225205 mentions this issue: test: make runindir tests pass regardless of whether module mode is in use

@bcmills bcmills removed the early-in-cycle A change that should be done early in the 3 month dev cycle. label Mar 24, 2020
@bcmills bcmills removed this from the Backlog milestone Mar 24, 2020
@bcmills bcmills added this to the Go1.15 milestone Mar 24, 2020
@golang golang locked and limited conversation to collaborators Mar 25, 2021
@rsc rsc unassigned bcmills Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done. Testing An issue that has been verified to require only test changes, not just a test failure.
Projects
None yet
Development

No branches or pull requests

6 participants