EscScope behaves like EscHeap in current code.
There are no need to handle it specially.
So remove it and use EscHeap instead.

Change-Id: I910106fd147f00e5f4fd52c7dde05128141a5160
Reviewed-on: https://go-review.googlesource.com/32130
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

The following benchmarks are improved by the amounts shown
(Others unaffected beyond the level of noise.)
Also adds a test to confirm non-SIMD implementation still correct,
even when run on SIMD-capable machine

Benchmark                   old            new
BenchmarkAddVV/100-18    66148.08 MB/s 117546.19 MB/s 1.8x
BenchmarkAddVV/1000-18   70168.27 MB/s 133478.96 MB/s 1.9x
BenchmarkAddVV/10000-18  67489.80 MB/s 100010.79 MB/s 1.5x
BenchmarkAddVV/100000-18 54329.99 MB/s  69232.45 MB/s 1.3x
BenchmarkAddVW/100-18     9929.10 MB/s  14841.31 MB/s 1.5x
BenchmarkAddVW/1000-18   10583.31 MB/s  18674.44 MB/s 1.76x
BenchmarkAddVW/10000-18  10521.15 MB/s  17484.10 MB/s 1.66x
BenchmarkAddVW/100000-18 10616.56 MB/s  18084.27 MB/s 1.7x

Change-Id: Ic9234c41a43f6c5e9d0e9377de8b4deeefc428a7
Reviewed-on: https://go-review.googlesource.com/32211Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The CloseWrite method sends a close_notify alert record to the other
side of the connection. This record indicates that the sender has
finished sending on the connection. Unlike the Close method, the sender
may still read from the connection until it recieves a close_notify
record (or the underlying connection is closed). This is analogous to a
TCP half-close.

This is a rework of CL 25159 with fixes for the unstable test.

Updates #8579

Change-Id: I47608d2f82a88baff07a90fd64c280ed16a60d5e
Reviewed-on: https://go-review.googlesource.com/31318Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Re-writing the switch statement as a single boolean expression
reduces the number of branches that the compiler generates.
It is also arguably easier to read as a pair of numeric ranges
that valid runes can exist in.

No test changes since the existing test does a good job of
testing all of the boundaries.

This change was to gain back some performance after a correctness
fix done in http://golang.org/cl/32123.

The correctness fix (CL/32123) slowed down the benchmarks slightly:
	benchmark                   old ns/op     new ns/op     delta
	BenchmarkIndexRune/10-4     19.3          21.6          +11.92%
	BenchmarkIndexRune/32-4     33.6          35.2          +4.76%

Since the fix relies on utf8.ValidRune, this CL improves benchmarks:
	benchmark                   old ns/op     new ns/op     delta
	BenchmarkIndexRune/10-4     21.6          20.0          -7.41%
	BenchmarkIndexRune/32-4     35.2          33.5          -4.83%

Change-Id: Ib1ca10a2e29c90e879a8ef9b7221c33e85d015d8
Reviewed-on: https://go-review.googlesource.com/32122
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #17621.

Change-Id: Id3e75c9b7fba2cf8e791c8817f890556ca238e9d
Reviewed-on: https://go-review.googlesource.com/32096Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

In all previous versions of Go, the behavior of IndexRune(s, r)
where r was utf.RuneError was that it would effectively return the
index of any invalid UTF-8 byte sequence (include RuneError).
Optimizations made in http://golang.org/cl/28537 and
http://golang.org/cl/28546 altered this undocumented behavior such
that RuneError would only match on the RuneError rune itself.

Although, the new behavior is arguably reasonable, it did break code
that depended on the previous behavior. Thus, we add special checks
to ensure that we preserve the old behavior.

There is a slight performance hit for correctness:
	benchmark                   old ns/op     new ns/op     delta
	BenchmarkIndexRune/10-4     19.3          21.6          +11.92%
	BenchmarkIndexRune/32-4     33.6          35.2          +4.76%
This only occurs on small strings. The performance hit for larger strings
is neglible and not shown.

Fixes #17611

Change-Id: I1d863a741213d46c40b2e1724c41245df52502a5
Reviewed-on: https://go-review.googlesource.com/32123
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

By using these utility functions, the code can be made a little shorter.
Thanks to Omar Shafie for pointing this out in
https://golang.org/cl/27393/.

Change-Id: I33fd97cf7d60a31d0844ec16c12bba530dcc6f6d
Reviewed-on: https://go-review.googlesource.com/32120
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

From lost-in-flight comments on CL 32190.

Change-Id: I2029cbac6d24b5944a796b359080011ec3a8da92
Reviewed-on: https://go-review.googlesource.com/32210Reviewed-by: Caleb Spare <cespare@gmail.com>
Reviewed-by: Martin Möhrmann <martisch@uos.de>

Fixes #16717

Change-Id: I7b6518609796a537437539c35461a18e9e6f207f
Reviewed-on: https://go-review.googlesource.com/32190Reviewed-by: Martin Möhrmann <martisch@uos.de>

Fixes #17534.

Change-Id: I28af74b287a5a09d5f6607a012f3d5d133b04ed2
Reviewed-on: https://go-review.googlesource.com/32017Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

- Removes a subject-verb disagreement.
- Documents that PATCH requests also populate PostForm.
- Explains that r.PostForm is always set (but blank for GET etc.).

Fixes #16609

Change-Id: I6b4693f8eb6db7c66fd9b9cd1df8927f50d46d50
Reviewed-on: https://go-review.googlesource.com/32091Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I40896fffbffefa359d08abda346933aa996f628d
Reviewed-on: https://go-review.googlesource.com/32124Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Don't include package path when creating LSyms for auto and param
variables during Prog generation, and update the DWARF emit routine
accordingly (remove the code that chops off package path from names in
DWARF var location expressions). Implementation suggested by mdempsky@.

The intent of this change is to have saner location expressions in cases
where the variable corresponds to a structure field. For example, the
SSA compiler's "decompose" phase can take a slice value and break it
apart into three scalar variables corresponding to the fields (slice "X"
gets split into "X.len", "X.cap", "X.ptr"). In such cases we want the
name in the location expression to omit the package path but preserve
the original variable name (e.g. "X").

Fixes #16338

Change-Id: Ibc444e7f3454b70fc500a33f0397e669d127daa1
Reviewed-on: https://go-review.googlesource.com/31819
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Updates #14204
Updates #16450
Updates #16100

Change-Id: Ic283bcec008a8e0bfbcfd8531d30fffe71052531
Reviewed-on: https://go-review.googlesource.com/32024Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #14493
Updates #6458 (changes its behavior)

Change-Id: I851a8113fd312dae3384e989ec2b70949dc22838
Reviewed-on: https://go-review.googlesource.com/21811
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>

Change-Id: I5ad338c90c311bd4cfdcd3d221a1f3e506a97d53
Reviewed-on: https://go-review.googlesource.com/32118
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Sometimes neither the src nor the dst of an escape edge
contains the line number appropriate to the edge, so add
a field so that can be set correctly.

Also updated some of the explanations to be less jargon-y
and perhaps more informative, and folded bug example into
test.

Cleaned up some of the function/method names in esc.go
and did a quick sanity check that each "bundling" function
was actually called often enough to justify its existence.

Fixes #17459.

Change-Id: Ieba53ab0a6ba1f7a6c4962bc0b702ede9cc3a3cc
Reviewed-on: https://go-review.googlesource.com/31660
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Change-Id: I6815a8560dd9fe0a0ebd485a0693f7044ba09848
Reviewed-on: https://go-review.googlesource.com/32137Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently, markroot delays scanning mark worker stacks until mark
termination by putting the mark worker G directly on the rescan list
when it encounters one during the mark phase. Without this, since mark
workers are non-preemptible, two mark workers that attempt to scan
each other's stacks can deadlock.

However, this is annoyingly asymmetric and causes some real problems.
First, markroot does not own the G at that point, so it's not
technically safe to add it to the rescan list. I haven't been able to
find a specific problem this could cause, but I suspect it's the root
cause of issue #17099. Second, this will interfere with the hybrid
barrier, since there is no stack rescanning during mark termination
with the hybrid barrier.

This commit switches to a different approach. We move the mark
worker's call to gcDrain to the system stack and set the mark worker's
status to _Gwaiting for the duration of the drain to indicate that
it's preemptible. This lets another mark worker scan its G stack while
the drain is running on the system stack. We don't return to the G
stack until we can switch back to _Grunning, which ensures we don't
race with a stack scan. This lets us eliminate the special case for
mark worker stack scans and scan them just like any other goroutine.
The only subtlety to this approach is that we have to disable stack
shrinking for mark workers; they could be referring to captured
variables from the G stack, so it's not safe to move their stacks.

Updates #17099 and #17503.

Change-Id: Ia5213949ec470af63e24dfce01df357c12adbbea
Reviewed-on: https://go-review.googlesource.com/31820
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

This issue has been fixed in CL 31271.

Fixes #8908.

Change-Id: I8015490e2d992e09c664560e42188315e0e0669e
Reviewed-on: https://go-review.googlesource.com/32150
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Now that SSA's write barrier pass is generating calls to these,
compile doesn't need to look them up.

Change-Id: Ib50e5f2c67b247ca280d467c399e23877988bc12
Reviewed-on: https://go-review.googlesource.com/32170
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

TestRemoveDevNull was added in CL 31657. However, this test
was failing on Plan 9, because /dev/null was considered as
a regular file.

On Plan 9, there is no special mode to distinguish between
device files and regular files.

However, files are served by different servers. For example,
/dev/null is served by #c (devcons), while /bin/cat is served
by #M (devmnt).

We chose to consider only the files served by #M as regular
files. All files served by different servers will be considered
as device files.

Fixes #17598.

Change-Id: Ibb1c3357d742cf2a7de15fc78c9e436dc31982bb
Reviewed-on: https://go-review.googlesource.com/32152Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This allows callers to invoke f.Usage() themselves and get the default
usage handler instead of a panic (from calling a nil function).

Fixes #16955.

Change-Id: Ie337fd9e1f85daf78c5eae7b5c41d5ad8c1f89bf
Reviewed-on: https://go-review.googlesource.com/31576
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Make the messages grammatically korrect and consistent.

Fixes #16844

Change-Id: I7c137b4dc25c0c875ed07b0c64c67ae984c39cbc
Reviewed-on: https://go-review.googlesource.com/32112Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

For some reason git won't let me write

	doc/effective_go.html: reword confusing sentence

or even

	doc/effective_go: reword confusing sentence

as the subject line for this CL, but that's not important. The
actual CL just rewrites one sentence and adds an option to grep in
the associated example.

Fixes #15875

Change-Id: Iee159ea751caf4b73eacf3dfc86e29032646373f
Reviewed-on: https://go-review.googlesource.com/32110Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently, if the number of stack barriers for a stack is 0, we'll
create a zero-length slice that points just past the end of the stack
allocation. This bad pointer causes GC panics.

Fix this by creating a nil slice if the stack barrier count is 0.

In practice, the only way this can happen is if
GODEBUG=gcstackbarrieroff=1 is set because even the minimum size stack
reserves space for two stack barriers.

Change-Id: I3527c9a504c445b64b81170ee285a28594e7983d
Reviewed-on: https://go-review.googlesource.com/31762Reviewed-by: Rick Hudson <rlh@golang.org>

This adds debug code enabled in gccheckmark mode that panics if we
attempt to mark an unallocated object. This is a common issue with the
hybrid barrier when we're manipulating uninitialized memory that
contains stale pointers. This also tends to catch bugs that will lead
to "sweep increased allocation count" crashes closer to the source of
the bug.

Change-Id: I443ead3eac6f316a46f50b106078b524cac317f4
Reviewed-on: https://go-review.googlesource.com/31761Reviewed-by: Rick Hudson <rlh@golang.org>

Currently reflectcall has a subtle dance with write barriers where the
assembly code copies the result values from the stack to the in-heap
argument frame without write barriers and then calls into the runtime
after the fact to invoke the necessary write barriers.

For the hybrid barrier (and for ROC), we need to switch to a
*pre*-write write barrier, which is very difficult to do with the
current setup. We could tie ourselves in knots of subtle reasoning
about why it's okay in this particular case to have a post-write write
barrier, but this commit instead takes a different approach. Rather
than making things more complex, this simplifies reflection calls so
that the argument copy is done in Go using normal bulk write barriers.

The one difficulty with this approach is that calling into Go requires
putting arguments on the stack, but the call* functions "donate" their
entire stack frame to the called function. We can get away with this
now because the copy avoids using the stack and has copied the results
out before we clobber the stack frame to call into the write barrier.
The solution in this CL is to call another function, passing arguments
in registers instead of on the stack, and let that other function
reserve more stack space and setup the arguments for the runtime.

This approach seemed to work out the best. I also tried making the
call* functions reserve 32 extra bytes of frame for the write barrier
arguments and adjust SP up by 32 bytes around the call. However, even
with the necessary changes to the assembler to correct the spdelta
table, the runtime was still having trouble with the frame layout (and
the changes to the assembler caused many other things that do strange
things with the SP to fail to assemble). The approach I took doesn't
require any funny business with the SP.

Updates #17503.

Change-Id: Ie2bb0084b24d6cff38b5afb218b9e0534ad2119e
Reviewed-on: https://go-review.googlesource.com/31655
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

The logic for saving the list of packages was not always
preferring to keep error messages around correctly.
The missed error led to an internal consistency failure later.

Fixes #17119.

Change-Id: I9723b5d2518c25e2cac5249e6a7b907be95b521c
Reviewed-on: https://go-review.googlesource.com/31812
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>

Fixes #17430

Change-Id: Ia1c25363d64e3091455ce00644438715aff30a0d
Reviewed-on: https://go-review.googlesource.com/31391
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Filippo Valsorda <hi@filippo.io>

Fixes #17409.

Change-Id: Ib49ff4a467431b5c1e6637e5144979cf0bfba489
Reviewed-on: https://go-review.googlesource.com/31817Reviewed-by: Martin Möhrmann <martisch@uos.de>
Reviewed-by: Quentin Smith <quentin@golang.org>

If we leave it for compilation sometimes the error appears first
in derived vendor paths, without any indication where they came from.
This is better.

$ go1.7 build canonical/d
cmd/go/testdata/src/canonical/a/a.go:3: non-canonical import path "canonical/a//vendor/c" (should be "canonical/a/vendor/c")
cmd/go/testdata/src/canonical/a/a.go:3: can't find import: "canonical/a//vendor/c"

$ go build canonical/d
package canonical/d
	imports canonical/b
	imports canonical/a/: non-canonical import path: "canonical/a/" should be "canonical/a"
$

Fixes #16954.

Change-Id: I315ccec92a00d98a08c139b3dc4e17dbc640edd0
Reviewed-on: https://go-review.googlesource.com/31668Reviewed-by: Quentin Smith <quentin@golang.org>

This is not strictly illegal but it probably should be (too late)
and doesn't mean what it looks like it means:
the second key-value pair has the key ",xml".

Fixes #14466.

Change-Id: I174bccc23fd28affeb87f57f77c6591634ade641
Reviewed-on: https://go-review.googlesource.com/32031
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>

This CL introduces some minor changes to match rules more closely
to the instructions they are targeting. s390x logical operation
with immediate instructions typically leave some bits in the
target register unchanged. This means for example that an XOR
with -1 requires 2 instructions. It is better in cases such as
this to create a constant and leave it visible to the compiler
so that it can be reused rather than hiding it in the assembler.

This CL also tweaks the rules a bit to ensure that constants are
folded when possible.

Change-Id: I1c6dee31ece00fc3c5fdf6a24f1abbc91dd2db2a
Reviewed-on: https://go-review.googlesource.com/31754Reviewed-by: Keith Randall <khr@golang.org>

Change-Id: I5c501f598f41241e6d7b21d98a126827a3c3ad9a
Reviewed-on: https://go-review.googlesource.com/32018Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently any warning will make dist fail because the
text will be considered as part of the package list.

Change-Id: I09a14089cd0448c3779e2f767e9356fe3325d8d9
Reviewed-on: https://go-review.googlesource.com/32111
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Use a single *struct{} type instance rather than reconstructing one
for every declared/imported interface method. Minor allocations win:

name       old alloc/op    new alloc/op    delta
Template      41.8MB ± 0%     41.7MB ± 0%  -0.10%         (p=0.000 n=9+10)
Unicode       34.2MB ± 0%     34.2MB ± 0%    ~           (p=0.971 n=10+10)
GoTypes        123MB ± 0%      122MB ± 0%  -0.03%         (p=0.000 n=9+10)
Compiler       495MB ± 0%      495MB ± 0%  -0.01%        (p=0.000 n=10+10)

name       old allocs/op   new allocs/op   delta
Template        409k ± 0%       408k ± 0%  -0.13%        (p=0.000 n=10+10)
Unicode         354k ± 0%       354k ± 0%    ~           (p=0.516 n=10+10)
GoTypes        1.22M ± 0%      1.22M ± 0%  -0.03%        (p=0.009 n=10+10)
Compiler       4.43M ± 0%      4.43M ± 0%  -0.02%        (p=0.000 n=10+10)

Change-Id: Id3a4ca3dd09112bb96ccc982b06c9e79f661d31f
Reviewed-on: https://go-review.googlesource.com/32051Reviewed-by: Robert Griesemer <gri@golang.org>

This reverts commit 7dd9c385.

Reason for revert: Reverting the revert, which will re-enable the convI2E optimization.  We originally reverted the convI2E optimization because it was making the builder fail, but the underlying cause was later determined to be unrelated.

Original CL: https://go-review.googlesource.com/31260
Revert CL: https://go-review.googlesource.com/31310
Real bug: https://go-review.googlesource.com/c/25159
Real fix: https://go-review.googlesource.com/c/31316

Change-Id: I17237bb577a23a7675a5caab970ccda71a4124f2
Reviewed-on: https://go-review.googlesource.com/32023
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

In the situation where the Client.Jar is set and the Request.Header
has cookies manually inserted, the redirect logic needs to be
able to apply changes to cookies from "Set-Cookie" headers to both
the Jar and the manually inserted Header cookies.

Since Header cookies lack information about the original domain
and path, the logic in this CL simply removes cookies from the
initial Header if any subsequent "Set-Cookie" matches. Thus,
in the event of cookie conflicts, the logic preserves the behavior
prior to change made in golang.org/cl/28930.

Fixes #17494
Updates #4800

Change-Id: I645194d9f97ff4d95bd07ca36de1d6cdf2f32429
Reviewed-on: https://go-review.googlesource.com/31435Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

It's only necessary to wrap named OTYPE or OLITERAL nodes, because
their line numbers reflect the line number of the declaration, rather
than use.

Saves a lot of wrapper nodes in composite-literal-heavy packages like
Unicode.

name       old alloc/op    new alloc/op    delta
Template      41.8MB ± 0%     41.8MB ± 0%  -0.07%        (p=0.000 n=10+10)
Unicode       36.6MB ± 0%     34.2MB ± 0%  -6.55%        (p=0.000 n=10+10)
GoTypes        123MB ± 0%      123MB ± 0%  -0.02%        (p=0.004 n=10+10)
Compiler       495MB ± 0%      495MB ± 0%  -0.03%        (p=0.000 n=10+10)

name       old allocs/op   new allocs/op   delta
Template        409k ± 0%       409k ± 0%  -0.05%        (p=0.029 n=10+10)
Unicode         371k ± 0%       354k ± 0%  -4.48%         (p=0.000 n=10+9)
GoTypes        1.22M ± 0%      1.22M ± 0%    ~           (p=0.075 n=10+10)
Compiler       4.44M ± 0%      4.44M ± 0%  -0.02%        (p=0.000 n=10+10)

Change-Id: Id1183170835125c778fb41b7e76d06d5ecd4f7a1
Reviewed-on: https://go-review.googlesource.com/32021
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>