Problem remains in:

go version devel +6b9c782f9f Wed Aug 1 00:57:00 2018 +0000 linux/amd64

I think this is intended behavior.

If run.go only imports standard-library packages, then I guess you could argue that it shouldn't require a go.mod file, but certainly if it imports anything from other modules we need to know what versions of those modules to use.

It seems awkward to have to look at the set of imports to determine whether we need a module definition: I'd rather we require it unconditionally.

Actually, I don't know why I thought this should work. You're quite right; if I can create an arbitrary .go file, I can trivially create an arbitrary go.mod file in the same directory, for example.

I'd be happy for this to be closed unless you think there's actually something to decide?

Actually @bcmills, I think there is some sort of issue here, even when I do create a go.mod file.

export GO111MODULE=on
sd=$(mktemp -d)
cd $sd
go mod init main
cat <<EOD > run.go
package main

import "fmt"

func main() {
        fmt.Println("Hello, world!")
}
EOD
go run run.go

succeeds and gives:

Hello, world!

Equally:

cd $(mktemp -d)
go run $sd/run.go

also gives:

Hello, world!

But then if I:

cd $(mktemp -d)
export GOPATH=$PWD
go run $sd/run.go

I get:

go: cannot find main module; see 'go help modules'

So it seems, with GO111MODULE=on, go run with a working directory within GOPATH doesn't work, whereas a working directory outside of GOPATH is fine (so long as I have a go.mod file).

Or do you think this is a duplicate of #26722?

I'm not sure, but we can certainly add some tests to cmd/go/testdata/script to describe what happens for that situation.

Confirmed that the repro in #26709 (comment) is solved by https://go-review.googlesource.com/c/go/+/127796 (the fix for #26722)

Will leave this open for, as @bcmills suggests, adding such a test case.

Please don't make go run require a go.mod. if anything, it should generate a temporary go.mod automatically and then throw it away.

Please don't make go run require a go.mod.

I would expect go run pkg@version to work with or without one (using the same mechanism as for #24250).

It's less clear to me whether go run in general should work outside a module. If the solution to #24250 is some sort of per-user fallback go.mod, then go run should clearly use that, but if we resolve #24250 in some other way then I'm not so confident. (So maybe that's an argument for the per-user fallback approach?)

@bcmills, is this fixed by the "in-memory empty go.mod" behavior we added?

Yes, go run is now tested (and works outside of a module).