Updates the s390x-specific files in these packages with the changes
to the amd64-specific files made during the review of CL 31690. I'd
like to keep these files in sync unless there is a reason to
diverge.

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

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

Change-Id: I174d7307bfdd8ec57bb4266dab8569fd2234abb4
Reviewed-on: https://go-review.googlesource.com/32610Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

SWIG generates cgo input files in the work directory. When those files
are passed directly to cgo, cgo generates long file names that include
the object directory (with slashes replaced by underscores). Instead,
use cgo's new -srcdir option to give it short file names.

When using both SWIG and cgo, copy the cgo files into the object
directory first.

Use a shorter object file name when compiling the C file generated by
SWIG.

Fixes #17070.

Change-Id: Ic558603f1731636d9999f3130ad0224b24bd7dcb
Reviewed-on: https://go-review.googlesource.com/32485
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

Updates #13451

Change-Id: I2c3c66d9532c16e616c476e2afe31b3ddc0a8d79
Reviewed-on: https://go-review.googlesource.com/32371Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Automated update after manual classification using x/build/cmd/writenotes.

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

In a function argument, we handle a typedef for a pointer specially,
using the pointer type rather than the typedef, to permit the Go calls
to match the laxer type conversions permitted in C. We record the
typedef so that we use that type in the C code, in case it has a special
attribute. However, using the typedef is wrong when using a pointer to a
basic type, because the C code may sometimes use the typedef and
sometimes not, and using the typedef in all cases will cause incorrect
type errors on the Go side. Fortunately we only really need to use the
typedef when pointing to a struct/union/class, and in such a case
confusion is unlikely.

Fixes #17723.

Change-Id: Id2eaeb156faeaf2e8eb9cf0b8f95b44caf8cfbd2
Reviewed-on: https://go-review.googlesource.com/32536
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

It's never set anywhere, and even if it was, it would just Fatalf.

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

Before aliases, and because we chose a simple export format for them,
a package may now export the same object more than once if there are
multiple exported aliases referring to that object. The go/importer
made the assumption this couldn't happen. Adjust it.

Fixes #17726.

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

Fixes #17697.

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

Since SWIG uses cgo, when using SWIG with gccgo, the go tool will add a
_cgo_flags file to the package archive, just as it does with cgo. We
need to remove that file from the archive passed to the linker, just as
we do with cgo.

Change-Id: I5ef4fea92eec419f870fbf6f678691d15901ee6c
Reviewed-on: https://go-review.googlesource.com/32535
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

This feels a bit like a layering violation, but as the bug report shows
it is sometimes necessary.

Fixes #17642

Change-Id: I4ba060bb1ce73a527ce276e5a769c44692b50016
Reviewed-on: https://go-review.googlesource.com/32236
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

A plugin with no exported symbols is still potentially very useful.
Its init functions are called on load, and it so it can have visible
side effects.

Fixes #17681

Change-Id: Icdca31f48e5ab13c99020a2ef724f3de47dcd74b
Reviewed-on: https://go-review.googlesource.com/32437
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

When we lookup a qualified identifier, we need to unpack
an alias. Do this in all places, not just one. Duh!

Fixes #17716.
For #17592.

Change-Id: I58d57b17cc635d0408b370f109c719c16757fd8e
Reviewed-on: https://go-review.googlesource.com/32534Reviewed-by: Alan Donovan <adonovan@google.com>

The runtime.typeEquals function is used during typelinksinit to
determine the canonical set of *_type values to use throughout the
runtime. As such, it is run against non-canonical *_type values, that
is, types from modules that are duplicates of a type from another
module that was loaded earlier in the program life.

These non-canonical *_type values sometimes contain pointers. These
pointers are pointing to position-independent data, and so they are set
by ld.so using dynamic relocations when the module is loaded. As such,
the pointer can point to the equivalent memory from a previous module.

This means if typesEqual follows a pointer inside a *_type, it can end
up at a piece of memory from another module. If it reads a typeOff or
nameOff from that memory and attempts to resolve it against the
non-canonical *_type from the later module, it will end up with a
reference to junk memory.

Instead, resolve against the pointer the offset was read from, so the
data is valid.

Fixes #17709.
Should no longer matter after #17724 is resolved in a later Go.

Change-Id: Ie88b151a3407d82ac030a97b5b6a19fc781901cb
Reviewed-on: https://go-review.googlesource.com/32513
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

When the err from ReadFile is non-nil, we call t.Fatal(err).
Switch t.Fatal to t.Error + return.
ensure that close(results) happens on that code path as well.

Updates #17697.

Change-Id: Ifaacf27a76c175446d642086ff32f4386428080d
Reviewed-on: https://go-review.googlesource.com/32486
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This makes no practical difference, as SIGSTOP can not be caught, but
may as well be consistent.

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

Change-Id: I49952f89b04f41109bb6591c6f025971d9880123
Reviewed-on: https://go-review.googlesource.com/32411Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David Symonds <dsymonds@golang.org>

Fixes #14353

Change-Id: I9cb5a5192ecdae37c100969395ed6a1564b8d34e
Reviewed-on: https://go-review.googlesource.com/32482
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Martin Möhrmann <martisch@uos.de>

IndexByte+compare is faster than indexShortStr in good case, when
first byte is rare, but is more costly in bad cases.
Start with IndexByte and switch to indexShortStr if we encounter
false positives more often than once per 8 bytes.

Benchmark changes for package bytes:

IndexRune/4K-8                    416ns ± 0%       86ns ± 0%    -79.24%        (p=0.000 n=10+10)
IndexRune/4M-8                    413µs ± 0%      100µs ± 1%    -75.88%        (p=0.000 n=10+10)
IndexRune/64M-8                  6.73ms ± 0%     2.86ms ± 1%    -57.49%        (p=0.000 n=10+10)
Index/10-8                       8.45ns ± 0%     8.96ns ± 0%     +6.04%         (p=0.000 n=9+10)
Index/32-8                       9.64ns ± 0%     9.51ns ± 0%     -1.30%          (p=0.000 n=8+9)
Index/4K-8                       2.11µs ± 0%     2.12µs ± 0%     +0.26%        (p=0.000 n=10+10)
Index/4M-8                       3.60ms ± 5%     3.59ms ± 7%       ~            (p=0.497 n=9+10)
Index/64M-8                      57.1ms ± 3%     58.7ms ± 5%       ~            (p=0.113 n=9+10)
IndexEasy/10-8                   7.10ns ± 1%     7.71ns ± 1%     +8.60%        (p=0.000 n=10+10)
IndexEasy/32-8                   9.29ns ± 1%     9.22ns ± 0%     -0.75%         (p=0.000 n=9+10)
IndexEasy/4K-8                   1.06µs ± 0%     0.08µs ± 0%    -92.18%        (p=0.000 n=10+10)
IndexEasy/4M-8                   1.07ms ± 0%     0.10ms ± 1%    -90.74%         (p=0.000 n=9+10)
IndexEasy/64M-8                  17.3ms ± 0%      2.8ms ± 1%    -83.76%         (p=0.000 n=10+9)

IndexRune/4K-8                 9.84GB/s ± 0%  47.42GB/s ± 0%   +381.85%         (p=0.000 n=8+10)
IndexRune/4M-8                 10.1GB/s ± 0%   42.1GB/s ± 1%   +314.56%        (p=0.000 n=10+10)
IndexRune/64M-8                10.0GB/s ± 0%   23.4GB/s ± 1%   +135.25%        (p=0.000 n=10+10)
Index/10-8                     1.18GB/s ± 0%   1.12GB/s ± 0%     -5.67%         (p=0.000 n=10+9)
Index/32-8                     3.32GB/s ± 0%   3.36GB/s ± 0%     +1.27%         (p=0.000 n=10+9)
Index/4K-8                     1.94GB/s ± 0%   1.93GB/s ± 0%     -0.25%         (p=0.000 n=10+9)
Index/4M-8                     1.17GB/s ± 5%   1.17GB/s ± 7%       ~            (p=0.497 n=9+10)
Index/64M-8                    1.17GB/s ± 3%   1.15GB/s ± 6%       ~            (p=0.113 n=9+10)
IndexEasy/10-8                 1.41GB/s ± 1%   1.30GB/s ± 1%     -7.90%        (p=0.000 n=10+10)
IndexEasy/32-8                 3.45GB/s ± 1%   3.47GB/s ± 0%     +0.73%         (p=0.000 n=9+10)
IndexEasy/4K-8                 3.84GB/s ± 0%  49.16GB/s ± 0%  +1178.78%         (p=0.000 n=9+10)
IndexEasy/4M-8                 3.91GB/s ± 0%  42.19GB/s ± 1%   +980.37%         (p=0.000 n=9+10)
IndexEasy/64M-8                3.88GB/s ± 0%  23.91GB/s ± 1%   +515.76%         (p=0.000 n=10+9)

No significant changes in strings.

In regexp I see:

Match/Easy0/32-8                 536MB/s ± 1%   540MB/s ± 1%    +0.75%         (p=0.001 n=9+10)
Match/Easy0/1K-8                1.62GB/s ± 0%  4.42GB/s ± 1%  +172.48%        (p=0.000 n=10+10)
Match/Easy0/32K-8               1.87GB/s ± 0%  9.07GB/s ± 1%  +384.24%         (p=0.000 n=7+10)
Match/Easy0/1M-8                1.90GB/s ± 0%  4.83GB/s ± 0%  +154.56%         (p=0.000 n=8+10)
Match/Easy0/32M-8               1.90GB/s ± 0%  4.53GB/s ± 0%  +138.62%         (p=0.000 n=7+10)

Compared to in 1.7:

Match/Easy0/32-8                  59.5ns ± 0%    59.2ns ± 1%   -0.45%         (p=0.008 n=9+10)
Match/Easy0/1K-8                   226ns ± 1%     231ns ± 1%   +2.30%        (p=0.000 n=10+10)
Match/Easy0/32K-8                 3.73µs ± 2%    3.61µs ± 1%   -3.12%        (p=0.000 n=10+10)
Match/Easy0/1M-8                   206µs ± 1%     217µs ± 0%   +5.34%        (p=0.000 n=10+10)
Match/Easy0/32M-8                 7.03ms ± 1%    7.40ms ± 0%   +5.23%        (p=0.000 n=10+10)

Fixes #17456

Change-Id: I38b2fabcaed7119cc4bf37007ba7bfe7504c8f9f
Reviewed-on: https://go-review.googlesource.com/31690
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
Reviewed-by: Keith Randall <khr@golang.org>

Fixes #17699

Change-Id: I7ea29a3fc2ca13d9d7e3044cbb8ea22e3435d423
Reviewed-on: https://go-review.googlesource.com/32484
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

This makes it possible to avoid tests where coverage affects the test
results by skipping them (or otherwise adjusting them) when coverage
is enabled.

Update #17699

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

Fixes #13290

Change-Id: I0f7e7683d86db501cbedb6a0b7349ceb0769701c
Reviewed-on: https://go-review.googlesource.com/32481Reviewed-by: Martin Möhrmann <martisch@uos.de>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

sigfwd calls an arbitrary C signal handler function.  The System V ABI
for x86_64 (and the most recent revision of the ABI for i386) requires
the stack to be 16-byte aligned.

Fixes: #17641

Change-Id: I77f53d4a8c29c1b0fe8cfbcc8d5381c4e6f75a6b
Reviewed-on: https://go-review.googlesource.com/32107
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Go's http1 implementation originally had a mechanism to send HTTP
trailers based on pre-declaring the trailer keys whose values you'd
later let after the header was written.

http2 copied the same mechanism, but it was found to be unsufficient
for gRPC's wire protocol. A second trailer mechanism was added later
(but only to http2) for handlers that want to send a trailer without
knowing in advance they'd need to.

Copy the same mechanism back to http1 and document it.

Fixes #15754

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

Skip TestObjdumpPowerManual if the host system is not ppc64 or ppc64le.
This test depends on using the host objdump and comparing output, which
does not work as expected if the test is run on another host.

Orignates from golang.org/x/arch/ppc64/ppc64asm commit 8e2d4898.

Fixes #17698

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

This should never be called but should help identify causes of
unexpected panics such as in issue #17716.

Change-Id: Id6ad0cef1088a41bfcc69110a93484a7e39c4128
Reviewed-on: https://go-review.googlesource.com/32480
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

Fixes #17683

Change-Id: I46f45c63796b58e8a8f14e37592231cbe7cd6934
Reviewed-on: https://go-review.googlesource.com/32438Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The introduction of -buildmode=plugin means modules can be added to a
Go program while it is running. This means there exists some time
while the program is running with the module is on the moduledata
linked list, but it has not been initialized to the satisfaction of
other parts of the runtime. Notably, the GC.

This CL adds a new way of access modules, an activeModules function.
It returns a slice of modules that is built in the background and
atomically swapped in. The parts of the runtime that need to wait on
module initialization can use this slice instead of the linked list.

Fixes #17455

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

There is no benefit to folding ADDconsts unless the resultant immediate
will fit into a 20-bit signed integer, so limit these rules accordingly.

Also the signed load operations were missing, so I've added them, and
I've also removed some MOVDaddr rules that were dead code (MOVDaddrs
are rematerializable on s390x which means they can't take inputs other
than SP or SB).

Change-Id: Iebeba78da37d3d71d32d4b7f49fe4ea9095d40ec
Reviewed-on: https://go-review.googlesource.com/30616
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>

- Adds overflow checks
- Adds parsing of negative integers
- Adds boolean return value to signal parsing errors
- Adds atoi32 for parsing of integers that fit in an int32
- Adds tests

Handling of errors to provide error messages
at the call sites is left to future CLs.

Updates #17718

Change-Id: I3cacd0ab1230b9efc5404c68edae7304d39bcbc0
Reviewed-on: https://go-review.googlesource.com/32390Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This implements a check that can be done at runtime for the ISA level and
hardware capability. It follows the same implementation as in s390x.

These checks will be important as we enable new instructions and write go
asm implementations using those.

Updates #15403
Fixes #16643

Change-Id: Idfee374a3ffd7cf13a7d8cf0a6c83d247d3bee16
Reviewed-on: https://go-review.googlesource.com/32330Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Use vector instructions to speed up indexing operations for short
strings (64 bytes or less).

bytes_s390x.go and strings_s390x.go are based on their amd64
equivalents in CL 31690.

bytes package:

name                   old time/op    new time/op    delta
Index/10                 40.3ns ± 7%    11.3ns ± 4%    -72.06%  (p=0.000 n=10+10)
Index/32                  196ns ± 1%      27ns ± 2%    -86.25%  (p=0.000 n=10+10)
Index/4K                 28.9µs ± 1%     1.5µs ± 2%    -94.94%    (p=0.000 n=9+9)
Index/4M                 30.1ms ± 2%     1.5ms ± 3%    -94.94%  (p=0.000 n=10+10)
Index/64M                 549ms ±13%      28ms ± 3%    -94.87%   (p=0.000 n=10+9)
IndexEasy/10             18.8ns ±11%    11.5ns ± 2%    -38.81%  (p=0.000 n=10+10)
IndexEasy/32             23.6ns ± 6%    28.1ns ± 3%    +19.29%  (p=0.000 n=10+10)
IndexEasy/4K              251ns ± 5%     223ns ± 8%    -11.04%  (p=0.000 n=10+10)
IndexEasy/4M              318µs ± 9%     266µs ± 8%    -16.42%  (p=0.000 n=10+10)
IndexEasy/64M            14.7ms ±16%    13.2ms ±11%    -10.22%  (p=0.001 n=10+10)

strings package:

name                   old time/op  new time/op  delta
IndexRune              88.1ns ±16%  28.9ns ± 4%  -67.20%  (p=0.000 n=10+10)
IndexRuneLongString     456ns ± 7%    34ns ± 3%  -92.50%  (p=0.000 n=10+10)
IndexRuneFastPath      12.9ns ±14%  11.1ns ± 6%  -13.84%  (p=0.000 n=10+10)
Index                  13.0ns ± 7%  11.3ns ± 4%  -13.31%  (p=0.000 n=10+10)
IndexHard1             3.38ms ± 9%  0.07ms ± 1%  -97.79%  (p=0.000 n=10+10)
IndexHard2             3.58ms ± 7%  0.37ms ± 2%  -89.78%  (p=0.000 n=10+10)
IndexHard3             3.47ms ± 7%  0.75ms ± 1%  -78.52%  (p=0.000 n=10+10)
IndexHard4             3.56ms ± 6%  1.34ms ± 0%  -62.39%    (p=0.000 n=9+9)

Change-Id: If36c2afb8c02e80fcaa1cf5ec2abb0a2be08c7d1
Reviewed-on: https://go-review.googlesource.com/32447
Run-TryBot: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

In a previous change, cmd/go was taught to show a "no tests ran" warning
if test did nothing. But it missed a case - if no tests nor examples ran
but any benchmarks were meant to be run, it would still produce the
warning. This meant that running only benchmarks, which is common, would
be confusing:

	 $ go test -run='^$' -bench=.
	testing: warning: no tests to run
	BenchmarkFoo-4            300000              5056 ns/op
	[...]

I believe this was because of a copy-paste error in the tests. This was
being tested, but on the wrong file which does contain a test that was
being run. Fix the path and fix the now failing test by never showing
the warning if -bench was given a non-empty string.

The rationale is that if -bench was given but there was no output, it's
obvious that nothing happened as benchmarks always produce output even
without -v. So showing a warning in those cases is redundant.

To make future typos less likely, make sure that no tests are being run
in the cases where we only want to run benchmarks.

Fixes #17603.

Change-Id: I4c626caf39f72260c6a9761c06446663f465f947
Reviewed-on: https://go-review.googlesource.com/32157Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Adds ModifyResponse, an optional func to ReverseProxy
that modifies a response in the backend, right before
the headers of the response are written to the internal
response writer.
If ModifyResponse returns an error, the proxy returns
a StatusBadGateway error.

Fixes #14237.

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

This CL expands upon a change made in (http://golang.org/cl/21811)
to ensure that a nil RawMessage gets serialized as "null" instead of
being a nil slice.

The added check only triggers when the RawMessage is nil. We do not
handle the case when the RawMessage is non-nil, but empty.

Fixes #17704
Updates #14493

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

If no error handler is provided, terminate parsing with first error
and report that error.

Fixes #17697.

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

Also updates x/net/http2 to git rev 541150 for:

   http2: add support for graceful shutdown of Server
   https://golang.org/cl/32412

   http2: make http2.Server access http1's Server via an interface check
   https://golang.org/cl/32417

Fixes #4674
Fixes #9478

Change-Id: I8021a18dee0ef2fe3946ac1776d2b10d3d429052
Reviewed-on: https://go-review.googlesource.com/32329
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

Currently we have write barriers for direct channel sends, where the
receiver is blocked and the sender is writing directly to the
receiver's stack; but not for direct channel receives, where the
sender is blocked and the receiver is reading directly from the
sender's stack.

This was okay with the old write barrier because either 1) the
receiver would write the received pointer into the heap (causing it to
be shaded), 2) the pointer would still be on the receiver's stack at
mark termination and we would rescan it, or 3) the receiver dropped
the pointer so it wasn't necessarily reachable anyway.

This is not okay with the write barrier because it lets a grey stack
send a white pointer to a black stack and then remove it from its own
stack. If the grey stack was the sole grey-protector of this pointer,
this hides the object from the garbage collector.

Fix this by making direct receives perform a stack-to-stack write
barrier just like direct sends do.

Fixes #17694.

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