We'll look into this, but the resolution might be that the go tool gives a better error message. It's not clear that it makes sense to build a test as an archive file.

Build test files without actually running the tests, just to check for
errors. This is what the syntastic plugin for vim does when you use it on a
_test.go file

On 27 August 2015 at 17:46, Minux Ma notifications@github.com wrote:

I don't think -buildmode=archive makes sense for go test. What are you
trying to achieve?

—
Reply to this email directly or view it on GitHub
#12359 (comment).

You can build the test files just using "test -c". I guess you are using the -buildmode=archive to skip the link step. If this is a useful feature, I think it would make more sense to file a separate issue asking for a cmd/go option to just build, and discard the output, and not link. This would be in effect a way to make sure that the files compile.

You can build tests without running them like this.

go test -run=XXX ./...

On Fri, 28 Aug 2015 02:52 Guilherme Salgado notifications@github.com
wrote:

Build test files without actually running the tests, just to check for
errors. This is what the syntastic plugin for vim does when you use it on a
_test.go file

On 27 August 2015 at 17:46, Minux Ma notifications@github.com wrote:

I don't think -buildmode=archive makes sense for go test. What are you
trying to achieve?

—
Reply to this email directly or view it on GitHub
#12359 (comment).

—
Reply to this email directly or view it on GitHub
#12359 (comment).

My main motivation is to be able to have something that runs real quick and reports errors when a developer saves a file they're editing. Ideally it should also report errors on other files within the same project, say, if I rename a function that is used somewhere else.

The reason why I started experimenting with -buildmode=archive is because in 1.5 builds became much slower; before 1.5, the hook was just doing a 'go test -c', which was fast enough in most cases.

If the check doesn't catch linking errors it's not a big deal, but yeah, it'd be nice if we could have 'go test -c' as fast as in pre-1.5 days

If you just want to check that the code is syntactically correct and typechecks correctly, it will almost certainly be faster to use something go/types-based, such as gotype (although gotype needs updating to use go/loader).

👍 to @josharian's suggestion

(although gotype needs updating to use go/loader).

We currently work around this by running run the two-step process of go install on the transitive set of all dependencies (including test) for a package spec, then concurrently running gotype -a on each package in the package spec (although we did get bitten by #18799).

I'm going to close this. It sounds like gotype is the solution. Also, each compiler release since Go 1.5 has gotten faster, and Go 1.9 is faster than Go 1.8.

Also, starting with Go 1.9, if you want to stick with cmd/compile and cmd/go, you can add -gcflags="-dolinkobj=false", which will speed things up considerably.