This CL also re-enables the cgo tests that were accidentally disabled
in CL 32754.

Fixes #18389.

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

Now with a few more repos included.

Add Albert Yu (individual CLA)
Add Alessandro Baffa (individual CLA)
Add Alexandre Fiori (individual CLA)
Add Andrew Austin (individual CLA)
Add Andy Finkenstadt (individual CLA)
Add Antonio Bibiano (individual CLA)
Add Baiju Muthukadan (individual CLA)
Add Ben Lubar (individual CLA)
Add Euan Kemp (individual CLA)
Add Harry Moreno (individual CLA)
Add Jason Buberel (corporate CLA for Google Inc.)
Add Joop Kiefte (individual CLA)
Add Maksym Trykur (individual CLA)
Add Mathieu Olivier (individual CLA)
Add Nick Leli (individual CLA)
Add Nik Nyby (individual CLA)
Add Quinn Slack (corporate CLA for Sourcegraph Inc)
Add Rafal Jeczalik (individual CLA)
Add Raphael Geronimi (individual CLA)
Add Ryan Bagwell (individual CLA)
Add Steve Francia (corporate CLA for Google Inc.)
Add Tristan Colgate (individual CLA)
Add Фахриддин Балтаев (individual CLA)

Updates #12042

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

Also retightens test cases for Resolve{TCP,UDP,IP}Addr which are using
interface names for specifying IPv6 zone.

Updates #14037.
Fixes #18362.

Change-Id: I7444b6302e2847dfbdab8a0ad5b2e702bed1a3d6
Reviewed-on: https://go-review.googlesource.com/34670
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

In CL 34650, LookupCNAME was changed so it always returns
the canonical DNS host, even when there is no CNAME record.

Consequently, TestLookupCNAME was failing on Plan 9,
because www.google.com doesn't have a CNAME record.

We changed the implementation of lookupCNAME on Plan 9, so it
returns the canonical DNS host after a CNAME lookup failure.

Fixes #18391.

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

Fixes #18105

Change-Id: Id56e8782ff618761ec44b6dc20891c8b48fea8df
Reviewed-on: https://go-review.googlesource.com/34632Reviewed-by: Rob Pike <r@golang.org>

Updates #18347
Updates #9348

Change-Id: I115203b0be3eb2e7e269ff28e2f3c47eeca86038
Reviewed-on: https://go-review.googlesource.com/34657Reviewed-by: Russ Cox <rsc@golang.org>

Updates #15157

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

Fixes #18172.

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

Stop-the-world and freeze-the-world (used for unhandled panics) are
currently not safe to do at the same time. While a regular unhandled
panic can't happen concurrently with STW (if the P hasn't been
stopped, then the panic blocks the STW), a panic from a _SigThrow
signal can happen on an already-stopped P, racing with STW. When this
happens, freezetheworld sets sched.stopwait to 0x7fffffff and
stopTheWorldWithSema panics because sched.stopwait != 0.

Fix this by detecting when freeze-the-world happens before
stop-the-world has completely stopped the world and freeze the STW
operation rather than panicking.

Fixes #17442.

Change-Id: I646a7341221dd6d33ea21d818c2f7218e2cb7e20
Reviewed-on: https://go-review.googlesource.com/34611
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Wait longer in case the system is heavily loaded.

Fixes #18324.

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

Fixes #18363.

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

Also tweak one of the comment lines to fit in 80 characters.

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

Piping into security verify-cert only worked on macOS Sierra, and was
flaky for unknown reasons. Users reported that the number of trusted
root certs stopped randomly jumping around once they switched to using
verify-cert against files on disk instead of /dev/stdin.

But even using "security verify-cert" on 150-200 certs took too
long. It took 3.5 seconds on my machine. More than 4 goroutines
hitting verify-cert didn't help much, and soon started to hurt
instead.

New strategy, from comments in the code:

// 1. Run "security trust-settings-export" and "security
//    trust-settings-export -d" to discover the set of certs with some
//    user-tweaked trusy policy. We're too lazy to parse the XML (at
//    least at this stage of Go 1.8) to understand what the trust
//    policy actually is. We just learn that there is _some_ policy.
//
// 2. Run "security find-certificate" to dump the list of system root
//    CAs in PEM format.
//
// 3. For each dumped cert, conditionally verify it with "security
//    verify-cert" if that cert was in the set discovered in Step 1.
//    Without the Step 1 optimization, running "security verify-cert"
//    150-200 times takes 3.5 seconds. With the optimization, the
//    whole process takes about 180 milliseconds with 1 untrusted root
//    CA. (Compared to 110ms in the cgo path)

Fixes #18203

Change-Id: I4e9c11fa50d0273c615382e0d8f9fd03498d4cb4
Reviewed-on: https://go-review.googlesource.com/34389
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>

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

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

This change reverts the following CLs:
	CL/18274: handle mtime in NTFS/UNIX/ExtendedTS extra fields
	CL/30811: only use Extended Timestamp on non-zero MS-DOS timestamps

We are reverting support for extended timestamps since the support was not
not complete. CL/18274 added full support for reading extended timestamp fields
and minimal support for writing them. CL/18274 is incomplete because it made
no changes to the FileHeader struct, so timezone information was lost when
reading and/or writing.

While CL/18274 was a step in the right direction, we should provide full
support for high precision timestamps in both the reader and writer.
This will probably require that we add a new field of type time.Time.
The complete fix is too involved to add in the time remaining for Go 1.8
and will be completed in Go 1.9.

Updates #10242
Updates #17403
Updates #18359
Fixes #18378

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

Parser doesn't attach some compiler directives to anything in the tree.
We have to explicitely retain them in the generated code. This change,
makes cover explicitely print out any compiler directive that wasn't
handled in the ast.Visitor.

Fixes #18285.

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

Fixes #18041.

Change-Id: Iad1439b2dd56b113c8829699eda467d1367b0e15
Reviewed-on: https://go-review.googlesource.com/34610Reviewed-by: Austin Clements <austin@google.com>

The runtime no longer hard-codes the offset of
reflect.methodValue.stack, so remove these obsolete comments. Also,
reflect.methodValue and runtime.reflectMethodValue must also agree
with reflect.makeFuncImpl, so update the comments on all three to
mention this.

This was pointed out by Minux on CL 31138.

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

Make sure we generate the right code for zeroing a structure.

Check in after Matthew's CL (34564).

Update #18370

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

Fixes #18191

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

golang.org/cl/31572 disabled some write barrier optimizations, but
inadvertantly disabled optimizations for some non-pointer composite
literal assignments too.

Fixes #18370.

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

Change-Id: Id0044c45c23c12ee0bca362a9cdd25369ed7776c
Reviewed-on: https://go-review.googlesource.com/34533
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

golang.org/issue/17594 was caused by additab being called more than once for
an itab. golang.org/cl/32131 fixed that by making the itabs local symbols,
but that in turn causes golang.org/issue/18252 because now there are now
multiple itab symbols in a process for a given (type,interface) pair and
different code paths can end up referring to different itabs which breaks
lots of reflection stuff. So this makes itabs global again and just takes
care to only call additab once for each itab.

Fixes #18252

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

Use the new "Deprecated:" syntax for all instances of HasPrefix.
This is a follow-up to http://golang.org/cl/28413 which only modified path_unix.go.

In this CL, we avoid mentioning that strings.HasPrefix should be used since
that function is still subtly wrong in security applications.

See http://golang.org/cl/5712045 for more information.

Fixes #18355

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

It takes me several minutes every time I want to find where the linker
writes out the _func structures. Add some comments to make this
easier.

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

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

Fixes #18181.

Change-Id: I5eed99dfb7b013aa4d4e668e95a97f5bb643d307
Reviewed-on: https://go-review.googlesource.com/34531
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

In the sampling tests, let the test pass if we get at least 10 samples.

Fixes #18332.

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

Confirm that a trivial executable can build and execute using
-fsanitize=memory.

Fixes #18335 (by skipping the tests when they don't work).

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

This fixes Linux and the *BSD platforms on 386/amd64.

A few OS/arch combinations were already saving registers and/or doing
something that doesn't clearly resemble the SysV C ABI; those have
been left alone.

Fixes #18328.

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

I haven't been able to reproduce this one, but change a few suspect
things in this test. Notably, using the global "Get" function and thus
using the DefaultTransport was buggy in a parallel test. Then add some error
checks and close a TCP connection.

Hopefully the failure wasn't timing-related.

Fixes #18036 (I hope)

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

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

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

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

Updates bundled x/net/http2 to git rev 1195a05d for:

    http2: fix incorrect panic
    https://golang.org/cl/34498

    http2: fix race in writePushPromise
    https://golang.org/cl/34493

    http2: speed up TestTransportFlowControl in short mode
    https://golang.org/cl/33241

    http2: don't flush a stream's write queue in sc.resetStream
    https://golang.org/cl/34238

    http2: allow Transport to connect to https://[v6literal]/ without port
    https://golang.org/cl/34143

    http2: log Framer reads and writes when a server test fails
    https://golang.org/cl/34130

Updates #18326
Updates #18273
Updates #18111
Updates #18248
Updates #18235

Change-Id: I18c7a297fc94d6a843284efcfc43e0fdab9b5f41
Reviewed-on: https://go-review.googlesource.com/34495
Run-TryBot: Chris Broadfoot <cbro@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

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

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

In Go 1.8, almost all the platforms except NaCl provide network
interface and address identification and applications can use IPv4
limited or directed broadcast addresses appropriately.

Fixes #18176.

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