We are seeing a bad stack map in #18190. In a copystack, it is
mistaking a slot for a pointer.

Presumably this is caused either by our fledgling dynlink support on
darwin, or a consequence of having two copies of the runtime in the
process. But I have been unable to work out which in the 1.8 window,
so pushing darwin support to 1.9 or later.

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

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

I meant to say ~7, instead of ^7, in the review.

Fix build.

Change-Id: I5060bbcd98b4ab6f00251fdb68b6b35767e5acf1
Reviewed-on: https://go-review.googlesource.com/34411
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Update #17617.

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

Change-Id: I7dd927be1e702e8fd469f4834ab918e0bcd9bafc
Reviewed-on: https://go-review.googlesource.com/34318Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #18305

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

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

Updates #12559.

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

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

Fixes #17792.

Change-Id: If4f24455eec0edb3b221aef6777a681f6c768866
Reviewed-on: https://go-review.googlesource.com/34313Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Explicitly filter any C-only cgo functions out of pclntable,
which allows them to be duplicated with the host binary.

Updates #18190.

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

The client code was using time.Now() (wall time) to determine whether
the cause of a non-nil error meant that a timeout had occured. But on
Windows, the clock used for timers (time.After, time.Sleep, etc) is
much more accurate than the time.Now clock, which doesn't update
often.

But it turns out that as of the recent https://golang.org/cl/32478 we
already have the answer available easily. It just wasn't in scope.

Instead of passing this information along by decorating the errors
(risky this late in Go 1.8, especially with #15935 unresolved), just
passing along the "didTimeout" func internally for now. We can remove
that later in Go 1.9 if we overhaul Transport errors.

Fixes #18287 (I hope)

Change-Id: Icbbfceaf02de6c7ed04fe37afa4ca16374b58f3c
Reviewed-on: https://go-review.googlesource.com/34381
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #18301.

Change-Id: I990c105904ab62f2225d671bbc10209ec51b12e2
Reviewed-on: https://go-review.googlesource.com/34371
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>

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

Drivers which previously supported tip will need to update to this
revision before release.

Fixes #18284

Change-Id: I70b8e7afff1558a8b5348885ce9f50e067c72ee9
Reviewed-on: https://go-review.googlesource.com/34330
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I9e24a28b4daee5d6e1e4769547922a1a253b4ffc
Reviewed-on: https://go-review.googlesource.com/34377Reviewed-by: Michael Munday <munday@ca.ibm.com>

Fixes #18175

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

document about the consecutive dialing introduced in Go 1.5.
If address is resolved to multiple addresses,
Dial will try each address in order until one succeeds.
Deadline is used to try each address (calculated based on
total number of resolved addresses)

Fixes: #17617

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

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

Now that we try to handle qualifiers correctly (as of CL 33325), don't
strip them from a void* pointer. Otherwise we break a case like "const
void**", as the "const" qualifier is dropped and the resulting
"void**" triggers a warning from the C compiler.

Fixes #18298.

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

Doc change only.

Fixes #18246.

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

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

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

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

A lot of things had to line up to make this break,
but the caching of download results interacted badly
with vendor directories, "go get -t -u", and wildcard
expansion.

Fixes #18219.

Change-Id: I2676498d2f714eaeb69f399e9ed527640c12e60d
Reviewed-on: https://go-review.googlesource.com/34201
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

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

Fixes #18283

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

The check for duplicate struct field tags introduced in CL 16704
triggers a panic when an anonymous struct field with a duplicate name
is encountered. For such a field, the names slice of the ast.Field is
nil but accessed regardless to generate the warning message.

Additionally, the check produces false positives for XML tags in some
cases:

- When fields are encoded as XML attributes, a warning is produced when
  an attribute reuses a name previously used for an element.

  Example:
    type Foo struct {
        First int `xml:"a"`
        NoDup int `xml:"a,attr"` // warning about reuse of "a"
    }

- When XMLName is used to set the name of the enclosing struct element,
  it is treated as a regular struct field.

  Example:
    type Bar struct {
        XMLName xml.Name `xml:"a"`
        NoDup   int      `xml:"a"` // warning about reuse of "a"
    }

This commit addresses all three issues. The panic is avoided by using
the type name instead of the field name for anonymous struct fields when
generating the warning message. An additional namespace for checking XML
attribute names separately from element names is introduced. Lastly,
fields named XMLName are excluded from the check for duplicate tags.

Updates #18256

Change-Id: Ida48ea8584b56bd4d12ae3ebd588a66ced2594cc
Reviewed-on: https://go-review.googlesource.com/34070
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

The test for the race detector itself had a race of a sort not
detected by the race detector.

Fixes #18286.

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

And move some code to make control flow more obvious.
No functional change.

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

Add Alexander Menzhinsky (individual CLA)
Add Anthony Woods (individual CLA)
Add Chris Stockton (individual CLA)
Add David Lazar (corporate CLA for Google Inc.)
Add Elliot Morrison-Reed (individual CLA)
Add Igor Bernstein (corporate CLA for Google Inc.)
Add Jesse Szwedko (individual CLA)
Add Jordan Lewis (individual CLA)
Add Kaviraj Kanagaraj (individual CLA)
Add Keegan Carruthers-Smith (individual CLA)
Add Marcel Edmund Franke (individual CLA)
Add Marin Bašić (individual CLA)
Add Martin Kreichgauer (corporate CLA for Google Inc.)
Add Max Riveiro (individual CLA)
Add Odin Ugedal (individual CLA)
Add Patrick Lee (individual CLA)
Add Rebecca Stambler (corporate CLA for Google Inc.)
Add Ryuzo Yamamoto (individual CLA)
Add Takuya Ueda (individual CLA)
Add Thordur Bjornsson (individual CLA)
Add Zac Bergquist (individual CLA)

Updates #12042

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

For the 1.8 release, go back to invoking the assembler once per .s
file, to avoid the problem in #18225. When the assembler is fixed, the
change to cmd/go/build.go can be rolled back, but the test in
cmd/go/go_test.go should remain.

Fixes #18225.
Update #15680.

Change-Id: Ibff8d0c638536efb50a2b2c280b41399332f4fe4
Reviewed-on: https://go-review.googlesource.com/34284
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This is the simplest CL that I can make for Go 1.8. For Go 1.9, we can revisit it
and optimize the redundant address generation instructions or just fix #599 instead.

Fixes #18140.

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

WITA stands for Asia/Makassar IANA timezone
https://en.wikipedia.org/wiki/Asia/Makassar

Fixes #18251

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

Also, if we changed the gsignal stack to match the stack we are
executing on, restore it when returning from the signal handler, for
safety.

Fixes #18255.

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

Fixes #18289

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

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

Change the openbsd runtime to use the current sys_kill and sys_thrkill
system calls.

Prior to OpenBSD 5.9 the sys_kill system call could be used with both
processes and threads. In OpenBSD 5.9 this functionality was split into
a sys_kill system call for processes (with a new syscall number) and a
sys_thrkill system call for threads. The original/legacy system call was
retained in OpenBSD 5.9 and OpenBSD 6.0, however has been removed and
will not exist in the upcoming OpenBSD 6.1 release.

Note: This change is needed to make Go work on OpenBSD 6.1 (to be
released in May 2017) and should be included in the Go 1.8 release.
This change also drops support for OpenBSD 5.8, which is already an
unsupported OpenBSD release.

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

Fixes #18282

Change-Id: I024ca4a03bbbcccd48a0a6245bc3ec22c6a90288
Reviewed-on: https://go-review.googlesource.com/34254
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Rob Pike <r@golang.org>

The pclntable contains pointers to functions. If the function symbol
is exported in a plugin, and there is a matching symbol in the host
binary, then the pclntable of a plugin ends up pointing at the
function in the host module.

This doesn't work because the traceback code expects the pointer to
be in the same module space as the PC value.

So don't export functions that might overlap with the host binary.
This way the pointer stays in its module.

Updates #18190

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