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.

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

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.

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

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

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

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.

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 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

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

@mvdan I did, see #32107

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?

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.

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.

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.

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.

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.

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