Currently the gctrace output reports the trigger heap size, rather
than the actual heap size at the beginning of GC. Often these are the
same, or at least very close. However, it's possible for the heap to
already have exceeded this trigger when we first check the trigger and
start GC; in this case, this output is very misleading. We've
encountered this confusion a few times when debugging and this
behavior is difficult to document succinctly.

Change the gctrace output to report the actual heap size when GC
starts, rather than the trigger.

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

Whenever someone pastes gctrace output into GitHub, it helpfully turns
the GC cycle number into a link to some unrelated issue. Prevent this
by removing the pound before the cycle number. The fact that this is a
cycle number is probably more obvious at a glance than most of the
other numbers.

Change-Id: Ifa5fc7fe6c715eac50e639f25bc36c81a132ffea
Reviewed-on: https://go-review.googlesource.com/12413Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #11839.

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

svn dies due to not being able to validate the googlecode.com certificate.
hg does not even attempt to validate it.

Fixes #11806.

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

Fixes TestGoGetWorksWithVanityWildcards,
but that test uses the network and is not run
on the builders.

For #11806.

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

This extends https://golang.org/cl/2811, which only applied to Darwin
and GNU/Linux, to all Unix systems.

Fixes #9591.

Change-Id: Iec3fb438564ba2924b15b447c0480f87c0bfd009
Reviewed-on: https://go-review.googlesource.com/12661
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Broke most builders.

This reverts commit a60c5366.

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

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

Fixes #11343.

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

Fixes #11020

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

From https://github.com/golang/go/issues/11745#issuecomment-123555313 :

The http.RoundTripper interface says you get either a *Response, or an
error.

But in the case of a client writing a large request and the server
replying prematurely (e.g. 403 Forbidden) and closing the connection
without reading the request body, what does the client want? The 403
response, or the error that the body couldn't be copied?

This CL implements the aforementioned comment's option c), making the
Transport give an N millisecond advantage to responses over body write
errors.

Updates #11745

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

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

Fixes #11872.

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

We used to use build.Import to get the dependencies, but that meant
we had to repeat the check for every possible GOOS/GOARCH/cgo
combination, which took too long. So we made the test in short mode
only check the current GOOS/GOARCH/cgo combination.
But some combinations can't run the test at all. For example darwin/arm64
does not run tests with a full source file systems, so it cannot test itself,
so nothing was testing darwin/arm64. This led to bugs like #10455
not being caught.

Rewrite the test to read the imports out of the source files ourselves,
so that we can look at all source files in a directory in one pass,
regardless of which GOOS/GOARCH/cgo/etc they require.
This one complete pass runs in the same amount of time as the
old single combination check ran, so we can now test all systems,
even in short mode.

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

This change adds new methods to Decoder.

 * Decoder.Token steps through a JSON document, returning a value for each token.
 * Decoder.Decode unmarshals the entire value at the token stream's current
   position (in addition to its existing function in a stream of JSON values)

Fixes #6050.
Fixes #6499.

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

A while back we discovered that the dependencies test allowed
arbitrary dependencies for packages we forgot to list.
To stop the damage we added a grandfathered list and fixed
the code to expect unlisted packages to have no dependencies.

This CL replaces the grandfathered list with some more
careful placement of dependency rules.

Thankfully, there were no terrible inversions.

Fixes #10487.

Change-Id: I5a6f92435bd2c66c47ec8ab629edbd88b189f028
Reviewed-on: https://go-review.googlesource.com/12575Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

It's not clear this really belongs anywhere at all,
but this is a better place for it than package os.
This way package os can avoid importing "C".

Fixes #10455.

Change-Id: Ibe321a93bf26f478951c3a067d75e22f3d967eb7
Reviewed-on: https://go-review.googlesource.com/12574Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>

It was not running because of invalid use of ArchChar.
I didn't catch this when I scrubbed ArchChar from the tree
because this code wasn't in the tree yet.

The test seems to pass, which is nice.

Change-Id: I59761a7a04a73681e147e25c1e7f010068276aa8
Reviewed-on: https://go-review.googlesource.com/12573Reviewed-by: Robert Griesemer <gri@golang.org>

There is clearly work to do here with respect to xml name spaces,
but I don't believe the changes in this cycle are clearly correct.
The changes in this cycle have visible impact on the generated xml,
possibly breaking existing programs, and yet it's not clear that they
are the end of the story: there is still significant confusion about how
name spaces work or should work (see #9519, #9775, #8167, #7113).

I would like to wait to make breaking changes until we completely
understand what the behavior should be and can evaluate the benefit
of those breaking changes. My main concern here is that we will break
programs in Go 1.5 for the sake of name space adjustments and then
while trying to fix those other bugs we'll break programs in Go 1.6 too.
Let's wait until we know all the changes we want to make before we
decide whether or how to break existing programs.

This CL reverts:

5ae822ba encoding/xml: minor changes
bb7e6656 encoding/xml: fix xmlns= behavior
9f9d66d3 encoding/xml: fix default namespace of tags
b69ea018 encoding/xml: fix namespaces in a>b tags
3be158d6 encoding/xml: encoding name spaces correctly

and adjusts tests from

a9dddb53 encoding/xml: add more EncodeToken tests.

to expect Go 1.4 behavior.

I have confirmed that the name space parts of the test suite
as of this CL passes against the Go 1.4 encoding/xml package,
indicating that this CL successfully restores the Go 1.4 behavior.

(Other tests do not, but that's because there were some real
bug fixes in this cycle that are being kept. Specifically, the
tests that don't pass in Go 1.4 are TestMarshal's NestedAndComment
case, TestEncodeToken's encoding of newlines, and
TestSimpleUseOfEncodeToken returning an error for invalid
token types.)

I also checked that the Go 1.4 tests pass when run against
this copy of the sources.

Fixes #11841.

Change-Id: I97de06761038b40388ef6e3a55547ff43edee7cb
Reviewed-on: https://go-review.googlesource.com/12570Reviewed-by: Nigel Tao <nigeltao@golang.org>

The "add a Request.Cancel channel" change (https://golang.org/cl/11601)
added support for "race free" cancellation, but introduced a data race. :)

Noticed while running "go test -race net/http". The test is skipped in
short mode, so we never saw it on the dashboard.

Change-Id: Ica14579d8723f8f9d1691e8d56c30b585b332c64
Reviewed-on: https://go-review.googlesource.com/12663Reviewed-by: Aaron Jacobs <jacobsa@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

Not everyone is aware that go build is a wrapper for other
tools. Mention this in the text for go help build so people using
other build systems won't just wrap go build, which is usually a
mistake (it doesn't do incremental builds by default, for instance).

Update #11854.

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

The system stack is only around 8kb on ARM so one can't put an 8kb buffer on
the stack. More than 1024 ARM cores seems sufficiently unlikely for the
foreseeable future.

Fixes #11853

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

Fixes #9530.

Change-Id: Iadfc027c7164e3ba35adb5c67deb42b51d3498ca
Reviewed-on: https://go-review.googlesource.com/12603Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dave Cheney <dave@cheney.net>

Currently TestDoDupSuppress can fail if the goroutines created by its
loop run sequentially. This is rare, but it has caused failures on the
dashboard and in stress testing.

While I think there's no way to eliminate all possible thread
schedules that could make this test fail because it depends on waiting
until a Group.Do blocks, it is possible to make it much more robust.

This commit deflakes this test by forcing at least one invocation of
fn to start and all goroutines to reach the line just before the Do
call before allowing fn to proceed. fn then waits 10 milliseconds
before returning to allow the goroutines to pass through the Do.

With this change, in 50,000 runs of the stress testing configuration,
the number of calls to fn never even exceeded 1.

Fixes #11784.

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

Update the docs to explain the code added in
commit 67e1d400.

Fixes #11831.

Change-Id: I8fe72e449507847c4bd9d77de40947ded7f2ff9d
Reviewed-on: https://go-review.googlesource.com/12515Reviewed-by: Dave Cheney <dave@cheney.net>

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

Issue 11214 reports problems with older versions of gdb.  It does work
with gdb 7.9 on my Ubuntu Trusty system, so take that as the minimum
required version.

Fixes #11214.

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

This adds documentation for all the environment variables I could
locate in the go tool and the commands that it invokes.

Fixes #9672.

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

Fixes #11847.

Change-Id: I21736a4c6f6fb2f61aec1396ce2c965e3e329e92
Reviewed-on: https://go-review.googlesource.com/12621Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>

In https://go-review.googlesource.com/#/c/8611/ , these tests were
supposed to be skipped only for linux and darwin, as the comment says.
This patch fixes the logic in the if test.

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

Old code appended, did not play well with a closure
with a ... param.

Fixes #11075.

Change-Id: Ib7c8590c5c4e576e798837e7499e00f3494efb4a
Reviewed-on: https://go-review.googlesource.com/12580Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>

This reverts commit b1177d39.

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

On Windows, gcc -o foo will generate foo.exe.  Prevent that from
happening by adding a final '.' if necessary so that GCC thinks that
the file already has an extension.

Also remove the initial output file when doing an external link, and
use mayberemoveoutfile, not os.Remove, when building an archive
(otherwise we will do the wrong thing for -buildmode=c-archive -o
/dev/null).

I didn't add a test, as it requires using cgo and -o on Windows.

Fixes #11725.

Change-Id: I6ea12437bb6b4b9b8ee5c3b52d83509fa2437b2d
Reviewed-on: https://go-review.googlesource.com/12243Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

See #10248 for details.

Fixes #10248.

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

Change-Id: If0821a2af987b78ed8024b40d9ffa68032518b22
Reviewed-on: https://go-review.googlesource.com/12572Reviewed-by: Robert Griesemer <gri@golang.org>

Limit probe to ODOT/OIND/ODOTPTR for now; that works.

Fixes #11790

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

EncodeToken takes a Token (i.e. an interface{}) as a parameter,
and expects a value of type StartElement, EndElement, CharData,
Comment, ProcInst, or Directive.

If a pointer is passed instead, or any type which does not match
this list, the token is silently ignored.

Added a default case in the type switch to issue a proper error
when the type is invalid.

The behavior could be later improved by allowing pointers to
token to be accepted as well, but not for go1.5.

Fixes #11719

Change-Id: Ifd13c1563450b474acf66d57669fdccba76c1949
Reviewed-on: https://go-review.googlesource.com/12252Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Foreign code can be arbitrarily aligned,
so the function before it can have
arbitrarily much padding.
We can't call pcvalue on values in the padding.

Fixes #11653.

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

Fixes #11606.

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