Fixes #11766
Fixes #11769
Fixes #11767
Fixes #11770

Change-Id: I441382af58f60deb46dcdd70076763b2c47738d4
Reviewed-on: https://go-review.googlesource.com/12378Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The default value for error is nil so there is no need to assign this
value here.

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

Update #11771.

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

This change adds site-local unicast classification for users still using
the deprecated addresses internally.

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

Old style. Make it compliant with our code review comments document.

Also, make WriteString's return parameter named 'n', not 'ret', for
consistency.

Noticed during another documentation review.

Change-Id: Ie88910c5841f8353bc5c0152e2168b497578e15e
Reviewed-on: https://go-review.googlesource.com/12324Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #11754

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

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

We shouldn't guarantee this behavior, but suggest it's possible.

Change-Id: I4c2afb48b99be4d91537306d3337171a13c9990a
Reviewed-on: https://go-review.googlesource.com/12346Reviewed-by: David Crawshaw <crawshaw@golang.org>

The change https://golang.org/cl/12192 changed the get code to use the
list of package imports, not the computed list of dependencies, as the
computed list could be out of date if the package changed when using
go get -u.  Computing the dependency list would skip an import of "C",
but that would still be on the package import list.  This changes the
code to skip "C" when walking the import list.

No test--the best test would be to add an import of "C" to
github.com/rsc/go-get-issue-9224-cmd for TestGoGetUpdate.

Fixes #11738.

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

Updates #10061

CL 12353 updated the documentation for os.Rename to stipulate the function will
return errors of type *os.LinkError. This CL adds a test to ensure that the
implementations continue to obey this contract.

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

No code changes. Just make it clear that runtime.GC is not concurrent.

Change-Id: I00a99ebd26402817c665c9a128978cef19f037be
Reviewed-on: https://go-review.googlesource.com/12345Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The document `doc/go_spec.html` uses "preceeding" instead of the word
"preceding" in one place.

Fixed another occurrence in `src/go/types/typexpr.go`.

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

Change-Id: I69ed001bca4987e08b46a8288f6feae2aca6a142
Reviewed-on: https://go-review.googlesource.com/12380Reviewed-by: David Crawshaw <crawshaw@golang.org>

Change-Id: I6e6d38ae347b4f5a33dff609b89785a038bc384c
Reviewed-on: https://go-review.googlesource.com/12304Reviewed-by: Andrew Gerrand <adg@golang.org>

An out-of-date comment snuck in to cc8f5441. Remove it.

Change-Id: I5bc7c17e737d1cabe57b88de06d7579c60ca28ff
Reviewed-on: https://go-review.googlesource.com/12328Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Rename should document that it returns *LinkError,
like Create and Stat do.

Fixes #10061

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

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

This fixes a race between 1) sweeping and freeing an unmarked large
span and 2) reusing that span and allocating from it. This race arises
because mSpan_Sweep returns spans for large objects to the heap
*before* heapBitsSweepSpan clears the mark bit on the object in the
span.

Specifically, the following sequence of events can lead to an
incorrectly zeroed bitmap byte, which causes the garbage collector to
not trace any pointers in that object (the pointer bits for the first
four words are cleared, and the scan bits are also cleared, so it
looks like a no-scan object).

1) P0 calls mSpan_Sweep on a large span S0 with an unmarked object on it.

2) mSpan_Sweep calls heapBitsSweepSpan, which invokes the callback for
   the one (unmarked) object on the span.

3) The callback calls mHeap_Free, which makes span S0 available for
   allocation, but this is too early.

4) P1 grabs this S0 from the heap to use for allocation.

5) P1 allocates an object on this span and writes that object's type
   bits to the bitmap.

6) P0 returns from the callback to heapBitsSweepSpan.
   heapBitsSweepSpan clears the byte containing the mark, even though
   this span is now owned by P1 and this byte contains important
   bitmap information.

This fixes this problem by simply delaying the mHeap_Free until after
the heapBitsSweepSpan. I think the overall logic of mSpan_Sweep could
be simplified now, but this seems like the minimal change.

Fixes #11617.

Change-Id: I6b1382c7e7cc35f81984467c0772fe9848b7522a
Reviewed-on: https://go-review.googlesource.com/12320
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>

Adjusts for the move from golang.org/x/tools/go/types and .../go/exact
to go/types and go/constant in the main repository.

Change-Id: I0da7248c540939e3e9b09c915b0a296937f1be73
Reviewed-on: https://go-review.googlesource.com/12284Reviewed-by: Andrew Gerrand <adg@golang.org>

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

Change-Id: I912cafc66463f81cde839afc8f06b7eadcbf6f57
Reviewed-on: https://go-review.googlesource.com/11992Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Update #10639

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

At least the most important parts, I think.

Fixes #10552

Change-Id: I1a03c5405bdbef337e0245d226e9247d3d067393
Reviewed-on: https://go-review.googlesource.com/12246Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

The iOS simulator compiles with GOOS=darwin GOARCH=386, and x509
sets the inappropriate flag -mmacosx-version-min=10.6. Condition
its compilation on the absence of an "ios" build tag.

Fixes #11736.

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

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

Also add a link to a couple of the talks from GopherCon 2015.

Change-Id: I11e1c550e999553163d3fb5e900f167c849ce33f
Reviewed-on: https://go-review.googlesource.com/12287Reviewed-by: Andrew Gerrand <adg@golang.org>

No code changes.

Change-Id: I3b78b1048318a4b80747fde8cab919282fc444a8
Reviewed-on: https://go-review.googlesource.com/12285Reviewed-by: Andrew Gerrand <adg@golang.org>

For #11656.

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

Broke arm64. Update #9880.

This reverts commit 38d9b2a3.

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

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

Updates #10639

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

This seems to have broken arm64 in a mysterious way. Will try again later.

This reverts commit 0a3c991f.

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

If we receive an HTTP request with "Expect: 100-continue" and the
Handler never read to EOF, the conn is in an unknown state.
Don't reuse that connection.

Fixes #11549

Change-Id: I5be93e7a54e899d615b05f72bdcf12b25304bc60
Reviewed-on: https://go-review.googlesource.com/12262Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Updates #10639

Change-Id: I0958e150f6eab122095bfc148746a38028b72dbc
Reviewed-on: https://go-review.googlesource.com/12263Reviewed-by: Andrew Gerrand <adg@golang.org>

Now that we care about the protocol of Git remotes (for the -insecure
flag), we need to recognize and parse the SCP-like remote format.

Fixes golang/go#11457

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

Running a safe-point function on syscall entry uses systemstack() and
hence clobbers g.sched.pc and g.sched.sp. Fix this by re-saving them
after the systemstack, just like in the other uses of systemstack in
reentersyscall.

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

Currently, we run a P's safe-point function immediately after entering
_Psyscall state. This is unsafe, since as soon as we put the P in
_Psyscall, we no longer control the P and another M may claim it.
We'll still run the safe-point function only once (because doing so
races on an atomic), but the P may no longer be at a safe-point when
we do so.

In particular, this means that the use of forEachP to dispose all P's
gcw caches is unsafe. A P may enter a syscall, run the safe-point
function, and dispose the P's gcw cache concurrently with another M
claiming the P and attempting to use its gcw cache. If this happens,
we may empty the gcw's workbuf after putting it on
work.{full,partial}, or add pointers to it after putting it in
work.empty. This will cause an assertion failure when we later pop the
workbuf from the list and its object count is inconsistent with the
list we got it from.

Fix this by running the safe-point function just before putting the P
in _Psyscall.

Related to #11640. This probably fixes this issue, but while I'm able
to show that we can enter a bad safe-point state as a result of this,
I can't reproduce that specific failure.

Change-Id: I6989c8ca7ef2a4a941ae1931e9a0748cbbb59434
Reviewed-on: https://go-review.googlesource.com/12124
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

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

There was already special code to recognize "?" in hidden_structdcl,
which is used for inlined types and variables.  This recognizes "?" in
structdcl as well, a case that arises when a struct type appears
within an inlined function body.

Fixes #10219.

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

Fixes #8837.

Change-Id: Iaaecbb0b324004cb74b16b764126b01315e6a16e
Reviewed-on: https://go-review.googlesource.com/12209Reviewed-by: Andrew Gerrand <adg@golang.org>