always enable race detector when testing

[rakyll]

No description provided.

[mvdan]

I usually leave both versions, go test and go test -race. Not particularly useful I guess, but if CI fails in the first, I know the race detector instrumentation had nothing to do with it. Thoughts?

[rakyll]

I don't truly understand. If someone is contributing code with a race condition, we should never merge that. There is practically no difference between introducing bugs by a change and introducing a race with a change.

[sdboyer]

There is practically no difference between introducing bugs by a change and introducing a race with a change.

I don't think @mvdan was arguing there is a difference - just that it's useful to quickly know what the cause of the test failure is. My colloquialism for this is "test failure locality" - how easy your tests/testing harness make it to understand exactly where the problem is. So, something like this is valuable for the same class of reason that golang/go#4899 is valuable.

I think I probably would prefer to have a run both with and without -race, at least for now. Test running times aren't too terrible, so doubling them isn't the end of the world. It's also helpful because our tests are really spammy right now, so it's already hard enough to locate where the problems are.

@jessfraz thoughts?

[rakyll]

It will obviously slow down the tests (and ugh, tests are already sloooooww). But, hey, that's why we run tests without the race detector locally when developing and want to depend on the CI to report them. I totally can add two lines (with and without race detector) but it will make waiting for CI even harder.

[sdboyer]

Eh, yeah, looking through travis and appveyor again...with spinup time, they already are frustratingly slow.

OK, let's just do the one, with -race on. (So, PR as-is, with conflicts resolved). We can always change it later :)

[mattn]

please rebase master.

[freeformz]

Thanks! I rebased and merged this.