code review 8797049: cmd/go: undo CL 8119049

cmd/go: undo CL 8119049

Manual undo due to later changes in doc/go1.1.html; cmd/go/test.bash still passes.

Rationale, from CL 8119049 review log:

This makes the 'go run' command different from every other command.
For example, 'go test' does not mean 'go test *.go'.

If we were going to handle the no arguments case in 'go run', I would hope that
it would scan the current directory to find a package just like 'go build' or
'go test' would, and then it would require that package to be 'package main',
and then it would run that package. This would make it match 'go test' and 'go
build' and 'go install' and so on. It would mean that if you are working on a
command in a directory that is 'go install'able, then 'go run' will run the
binary for you. The current CL does not accomplish that when build constraints
or file name constraints are involved.

For example, if I am working on a program like:

$ ls
main.go
main_386.s
main_arm.s
main_amd64.s
$

Then 'go run' will fail here because the .s files are ignored.

If instead I am working on a program like:

$ ls
main.go
main_386.go
main_arm.go
main_amd64.go
$

then 'go run' will fail because too many files are included.

I would like to see this command implemented so that it is compatible with the
other go subcommands. Since it is too late to do that for Go 1.1, I would like
to see this CL reverted, to preserve the option to do it better later.

[rsc, 2013-04-29 19:04:15]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go/

[iant, 2013-04-29 19:12:03]

LGTM

Please reopen issue 5164.

[r, 2013-04-29 19:26:06]

LGTM

[rsc, 2013-04-30 21:05:01]

*** Submitted as https://code.google.com/p/go/source/detail?r=dddf80567e0d ***

cmd/go: undo CL 8119049

Manual undo due to later changes in doc/go1.1.html; cmd/go/test.bash still
passes.

Rationale, from CL 8119049 review log:

This makes the 'go run' command different from every other command.
For example, 'go test' does not mean 'go test *.go'.

If we were going to handle the no arguments case in 'go run', I would hope that
it would scan the current directory to find a package just like 'go build' or
'go test' would, and then it would require that package to be 'package main',
and then it would run that package. This would make it match 'go test' and 'go
build' and 'go install' and so on. It would mean that if you are working on a
command in a directory that is 'go install'able, then 'go run' will run the
binary for you. The current CL does not accomplish that when build constraints
or file name constraints are involved.

For example, if I am working on a program like:

$ ls
main.go
main_386.s
main_arm.s
main_amd64.s
$

Then 'go run' will fail here because the .s files are ignored.

If instead I am working on a program like:

$ ls
main.go
main_386.go
main_arm.go
main_amd64.go
$

then 'go run' will fail because too many files are included.

I would like to see this command implemented so that it is compatible with the
other go subcommands. Since it is too late to do that for Go 1.1, I would like
to see this CL reverted, to preserve the option to do it better later.

R=golang-dev, iant, r
CC=golang-dev
https://codereview.appspot.com/8797049