Comment 2:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

Comment 3:

Labels changed: added priority-later, removed priority-triage.

Status changed to Thinking.

Comment 4:

Labels changed: added go1.2maybe.

Comment 5:

Labels changed: added feature.

Comment 6:

Too magic for my taste. Reopen if you can make a compelling argument.

Status changed to Fixed.

Comment 7:

This issue was closed as Fixed, but it was not fixed.
It is causing issues with tools that want to check if a file can be built successfully,
without actually creating a binary. flychecker for example is a very popular emacs tool
that does syntax checking for many languages. Its support for go uses the output of "go
build" to figure out where syntax errors exist and highlight them. 
flycheck/flycheck#107 
http://flycheck.github.io/
Also, I don't think it is "too magic". The concept of a null device is pretty standard,
and even supported in go as const os.DevNull (/dev/null for *nix, NUL for windows, etc).
The fix seems pretty straightforward. Only copy final target file if destination is not
os.DevNull. 
i.e. end (*builder).install method with:
    if a.target == os.DevNull {
        return nil
    }
    return b.copyFile(a, a.target, a1.target, perm)

Comment 8:

i suspect using "go build" just to test syntax is not correct as it invokes the
whole toolchain.
why not just let the go tool create a binary in $TMPDIR? and then delete it?
(please note that the Go tool is already creating the final binary, so i believe
we can't gain anything by output to /dev/null)

Comment 9:

re: "just testing syntax", saying that it does syntax checking was probably incorrect.
It does want to do a whole compile + link to catch the same errors that a `go build`
would report.
re: $TMPDIR, that's probably generally a better idea. It's not any less
platform-specific than /dev/null would be and doesn't require any changes. In a way,
using /dev/null would be "too magic". Go doesn't write to a device, it creates a file,
so handling /dev/null would be special and not the same meaning as the Unix meaning of
it.

Comment 10:

not any more platform-specific, of course.

Comment 11:

Note:
if you name every Go source file on the command line, "go build -o /dev/null" will work.
to support import paths, some go list trickery is required:
go build -o /dev/null $(go list -f $'{{range $f := .GoFiles}}{{$.Dir}}/{{$f}}\n{{end}}'
cmd/go)

Comment 12:

Simple workaround (albeit a bit cutesy):
go build . errors

Comment 13 by quintus.public:

This would be nice to be able to throw out the resulting binary to simplify the last leg
of the test cycle. Especially with the fix mentioned in #8, it seems like an easy and
trivial change to make.