code review 112290043: src, misc: applied gofmt -s -w

src, misc: applied gofmt -s -w

Pending CL 113120043.

[gri, 2014-07-14 23:41:32]

Hello golang-codereviews@googlegroups.com,

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

[dave_cheney.net, 2014-07-14 23:49:01]

LGTM. Wow, I never imagined this pattern would be so common.

https://codereview.appspot.com/112290043/diff/30018/src/pkg/runtime/mapspeed_...
File src/pkg/runtime/mapspeed_test.go (right):

https://codereview.appspot.com/112290043/diff/30018/src/pkg/runtime/mapspeed_...
src/pkg/runtime/mapspeed_test.go:253: for range m {
It doesn't happen now, but I can see in the future the compiler could ignore
this entire loop as it has no side effect.

[gri, 2014-07-14 23:57:17]

Yes, I was a bit surprised about the number of occurrences myself.

https://codereview.appspot.com/112290043/diff/30018/src/pkg/runtime/mapspeed_...
File src/pkg/runtime/mapspeed_test.go (right):

https://codereview.appspot.com/112290043/diff/30018/src/pkg/runtime/mapspeed_...
src/pkg/runtime/mapspeed_test.go:253: for range m {
On 2014/07/14 23:49:01, dfc wrote:
> It doesn't happen now, but I can see in the future the compiler could ignore
> this entire loop as it has no side effect.

Haven't checked but I thought using _ was already treated like there was no key.
But I might be wrong.

[gri, 2014-07-16 23:29:54]

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

src, misc: applied gofmt -s -w

Pending CL 113120043.

LGTM=dave
R=golang-codereviews, dave
CC=golang-codereviews
https://codereview.appspot.com/112290043

[gobot, 2014-07-17 01:25:21]

This CL appears to have broken the netbsd-amd64-bsiegert builder.
See http://build.golang.org/log/42e89e40df2b6fe94e3849be2316f943acec9ddb