cmd/go: build panics or prints warning twice when import path pattern matches 0 packages

[dmitshur]

What does 'go version' print?

go version devel +00224712f89e Fri Jun 06 16:52:14 2014 -0400 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. go list ...does_not_exist
2. go build ...does_not_exist
3. go build -o ./out ...does_not_exist

What happened?

The first command works correctly, printing a single warning.
The second command works, but prints the warning twice.
The third command prints a warning one time, and then panics with "runtime error:
index out of range".

1.

warning: "...does_not_exist" matched no packages

2.

warning: "...does_not_exist" matched no packages
warning: "...does_not_exist" matched no packages

3.

warning: "...does_not_exist" matched no packages
panic: runtime error: index out of range

goroutine 16 [running]:
runtime.panic(0x7f5740, 0xa7a67c)
    /home/dmitri/Dmitri/go/src/pkg/runtime/panic.c:279 +0xf5
main.runBuild(0xa774c0, 0xc20800e040, 0x1, 0x1)
    /home/dmitri/Dmitri/go/src/cmd/go/build.go:291 +0x442
main.main()
    /home/dmitri/Dmitri/go/src/cmd/go/main.go:162 +0x55a

goroutine 19 [finalizer wait]:
runtime.park(0x46de70, 0xa7ec10, 0xa7ce89)
    /home/dmitri/Dmitri/go/src/pkg/runtime/proc.c:1369 +0x89
runtime.parkunlock(0xa7ec10, 0xa7ce89)
    /home/dmitri/Dmitri/go/src/pkg/runtime/proc.c:1385 +0x3b
runfinq()
    /home/dmitri/Dmitri/go/src/pkg/runtime/mgc0.c:2644 +0xcf
runtime.goexit()
    /home/dmitri/Dmitri/go/src/pkg/runtime/proc.c:1445

goroutine 20 [syscall]:
os/signal.loop()
    /home/dmitri/Dmitri/go/src/pkg/os/signal/signal_unix.go:21 +0x1e
created by os/signal.init·1
    /home/dmitri/Dmitri/go/src/pkg/os/signal/signal_unix.go:27 +0x32

goroutine 21 [runnable]:
text/template/parse.lexText(0xc20804c100, 0x915150)
    /home/dmitri/Dmitri/go/src/pkg/text/template/parse/lex.go:228 +0x381
text/template/parse.(*lexer).run(0xc20804c100)
    /home/dmitri/Dmitri/go/src/pkg/text/template/parse/lex.go:198 +0x40
created by text/template/parse.lex
    /home/dmitri/Dmitri/go/src/pkg/text/template/parse/lex.go:191 +0x112

What should have happened instead?

All three commands should result in the same output, a single warning that the pattern
matched zero packages. There shouldn't be two identical warnings, and there shouldn't be
a panic.

Please provide any additional information below.

[ianlancetaylor]

Comment 1:

Labels changed: added repo-main, release-go1.4.

[dmitshur]

Comment 2:

The panic is very easy to fix, that panic stack trace points directly to the problem (`p
:= pkgs[0]` is done, but there's no check if `len(pkgs) == 0`).
However, I'm not sure what's a better correct behavior for `go build -o ./out
...does_not_exist`. There are two choices. Either a warning and no output like the other
commands.
Alternatively, maybe the best thing to do for `go build -o ./out ...does_not_exist` is
the same as for `go build -o ./out ...matches_multiple_pkgs`, which is:
fatalf("go build: cannot use -o with multiple packages")
It's a design decision of, if the user specifies -o option, should the command always
write _some_ output and fail with error if it can't (i.e. either matches multiple
packages, or no packages, or build error, etc.). Or should it write output if pattern
matches one package, but do nothing when pattern matches no packages.
Thinking about it more, I think I would prefer it to be more consistent and fail if
pattern matches multiple or 0 packages, which can be done by changing:
    if len(pkgs) > 1 {
        fatalf("go build: cannot use -o with multiple packages")
    }
to:
    if len(pkgs) != 1 {
        fatalf("go build: cannot use -o with multiple packages")
    } else if len(pkgs) < 1 {
        fatalf("go build: cannot use -o with no packages")
    }
Or something along those lines.
That way, if someone has a script that executes `go build -o binary_name ...some_pkg`,
that command will only return success status if ./binary_name is successfully written,
and hence it's more reliable.

[dmitshur]

Comment 3:

The panic is very easy to fix, that panic stack trace points directly to the problem (`p
:= pkgs[0]` is done, but there's no check if `len(pkgs) == 0`).
However, I'm not sure what's a better correct behavior for `go build -o ./out
...does_not_exist`. There are two choices. Either a warning and no output like the other
commands.
Alternatively, maybe the best thing to do for `go build -o ./out ...does_not_exist` is
the same as for `go build -o ./out ...matches_multiple_pkgs`, which is:
fatalf("go build: cannot use -o with multiple packages")
It's a design decision of, if the user specifies -o option, should the command always
write _some_ output and fail with error if it can't (i.e. either matches multiple
packages, or no packages, or build error, etc.). Or should it write output if pattern
matches one package, but do nothing when pattern matches no packages.
Thinking about it more, I think I would prefer it to be more consistent and fail if
pattern matches multiple or 0 packages, which can be done by changing:
    if len(pkgs) > 1 {
        fatalf("go build: cannot use -o with multiple packages")
    }
to:
    if len(pkgs) > 1 {
        fatalf("go build: cannot use -o with multiple packages")
    } else if len(pkgs) < 1 {
        fatalf("go build: cannot use -o with no packages")
    }
Or something along those lines.
That way, if someone has a script that executes `go build -o binary_name ...some_pkg`,
that command will only return success status if ./binary_name is successfully written,
and hence it's more consistent and reliable.

[gopherbot]

Comment 4:

CL https://golang.org/cl/107140043 mentions this issue.

[adg]

Comment 5:

This issue was closed by revision 3e80141.

Status changed to Fixed.