[release-branch.go1.5] go1.5

This updates the VERSION file.
The release proper has not happened yet.

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

[release-branch.go1.5] cmd/newlink: remove from release branch

Change-Id: Iad86bde6f2e0482745a4000ec4e192ade352983b
Reviewed-on: https://go-review.googlesource.com/13292
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

runtime: set invalidptr=1 by default, as documented

Also make invalidptr control the recently added GC pointer check,
as documented.

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

runtime: don't free large spans until heapBitsSweepSpan returns

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 golang#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>

cmd/go: disable vendoredImportPath for code outside $GOPATH

It was crashing.
This fixes the build for
GO15VENDOREXPERIMENT=1 go test -short runtime

Fixes golang#11416.

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

[release-branch.go1.4] go1.4.2

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

[release-branch.go1.4] go1.4.1

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

go1.4

LGTM=bradfitz, minux, dsymonds
R=rsc, bradfitz, iant, dsymonds, minux
CC=golang-codereviews
https://golang.org/cl/188920043

go1.4rc2

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/179700043

[release-branch.go1.4] remove cmd/link from nacl test zip

LGTM=dsymonds
R=rsc, dsymonds
CC=golang-codereviews
https://golang.org/cl/179830043