From https://golang.org/cmd/go/#hdr-Description_of_package_lists:

Directory and file names that begin with "." or "_" are ignored by the go tool, as are directories named "testdata".

@davecheney I know you have a personal dislike for go run, but it is an incredibly useful command, and it is a part of the go toolchain that isn't going away (afaik), and thus we should try to make it work in the best way possible. At the very least it should not be misleading and frustrating.

The message should be made consistent with the rest of the examples (and perhaps docs updated). But ideally, I'd like it to just run the files I give it if they're .go files.

I tried with go1.8.3. The error message is slightly different, but it's the same idea:

package main: no buildable Go source files in /Users/Gopher/go/src/new/package

I want go developers to stop leaning on go run,

Me too, but we shouldn't conflate bugs/inconsistencies with our desires to demote some feature that Go officially supports.

@kshvmdn, I am extremely familiar with that, but my understanding was that it applied for normal Go packages specified by import paths only. go run operates on .go files provided to it, and does not support Go packages specified via import paths.

If you look at the topic of the section where what you quoted is, it starts with:

Many commands apply to a set of packages:

go action [packages]

Usually, [packages] is a list of import paths.

And what follows sounds like it only apples to those commands.

However, upon closer look, I noticed the paragraph preceding what you quoted:

As a special case, if the package list is a list of .go files from a single directory, the command is applied to a single synthesized package made up of exactly those files, ignoring any build constraints in those files and ignoring any other files in the directory.

Directory and file names that begin with "." or "_" are ignored by the go tool, as are directories named "testdata".

I think that means the current go run behavior is correct/as expected.

What we need to consider next is whether the documentation and the error message text is optimal. I'm going to look into it more before I make further comments.

I've confirmed that go run has the same behavior as described in that section regarding .go files being in the same directory. If they are not, you get this error:

$ touch another.go
$ open another.go 
$ go run main.go another.go 
another
go
$ mkdir dir
$ mv another.go dir/another.go
$ go run main.go dir/another.go
named files must all be in one directory; have ./ and dir/
$ go build main.go dir/another.go
named files must all be in one directory; have ./ and dir/
$ go install main.go dir/another.go
named files must all be in one directory; have ./ and dir/

This is definitely not a behavior bug. However, I suspect the current go run documentation could be improved. Its wording seems to imply it has its own behavior, but it turns out that it works with ad-hoc packages no different than go build and go install.

@davecheney Did you see my comments above? I found out that this is not a bug, there is an explanation for the current go run behavior. It behaves identically as go build and go install (and go test) do on ad-hoc packages (packages specified as a list of .go files in a single directory).

The only potential issue is that the documentation of this behavior is far away from the docs of go run command, and the phrasing in go run command makes it sound like go run behavior is unique, when in reality it isn't.

is there another way to solve the problem you had without making go run even more special?

I'm not sure which "you" you're referring to. If it's me, I don't have a problem that I was solving with go run and I'm not suggesting we change it's behavior to make it special. I just want to see if it's possible to improve the docs so its current correct behavior is more clear.

run command skips .go files starting with _ or . characters

IINM, this has nothing to do with the 'run' command. dotfiles and _* are ignored by the whole toolchain. I believe it is already documented somewhere, but I was not able to now find where.

There are 2 separate changes I want to consider that I think will resolve this issue. The first one is improving cmd/go docs, the second is improving the error message when doing go (run|build|install|test) _underscore.go (if it's viable to do so cleanly).

The main one is making thecmd/go documentation more accurate about what go run does. When someone reads the following part of the Description of package lists section:

As a special case, if the package list is a list of .go files from a single directory, the command is applied to a single synthesized package made up of exactly those files, ignoring any build constraints in those files and ignoring any other files in the directory.

Directory and file names that begin with "." or "_" are ignored by the go tool, as are directories named "testdata".

I want users to be able to understand that applies to go run and it's precisely the only input go run accepts.

Currently, go run docs say something that imply that it has similar but different behavior:

Run compiles and runs the main package comprising the named Go source files. A Go source file is defined to be a file ending in a literal ".go" suffix.

Here's a first stab/draft at a more accurate description of go run behavior, but also one that should hopefully communicate that it behaves the same as go build, go install, etc., do on a list of .go files.

Run compiles and runs a single synthesized main package comprising the named
.go files from a single directory, ignoring any build constraints
in those files and ignoring any other files in the directory.
File names that begin with "." or "_" are also ignored.

That seems accurate and easy to recognize the similarity, but I don't like the first sentence. It jumps into details and doesn't do a great job communicating the overview of what the command does. The original is much better:

Run compiles and runs the main package comprising the named Go source files.

Maybe there's a way to keep that as is, but modify the rest of the text to follow... Suggestions appreciated.

See also #21045. It may be a bug to be skipping those files if named explicitly.

I think CL 109341 (for issue #22726) has helped this issue somewhat (at least, it implemented a part of what I described in my comment from Aug 20 above). /cc @rsc

If you run go run (or build or test or ...) with a list of .go file names, it should use that list. That's #21045.

This issue can be to document that the file names must all be in the same directory.

Change https://golang.org/cl/149797 mentions this issue: cmd/go/internal/{run,work}: document file path location requirement