Default user agent in use - "Go 1.1 package http" doesn't conform to RFC 7231.
See http://tools.ietf.org/html/rfc7231#section-5.5.3

Use a valid user-agent string instead.

Fixes #9792

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

All other exported errors in net/http are commented.  This change adds
documentation to ErrNoCookie and ErrNoLocation to explain where they are
returned, and why.

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

This adds a GC bitmap test of a type with many pointer bits and a
large scalar tail, such as the one in issue #11286. This test would
have failed prior to the fix in a8ae93fd. This test is a more direct
version of the test introduced in that commit (which was distilled
from the failing test in the issue).

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

Currently we test bitmap repetitions constructed by the compiler (for
small arrays) and repetitions performed by GC programs (large arrays
and reflect-constructed arrays), but we don't test dynamic repetitions
performed by the runtime for slice backing stores. Add tests that
parallel the array tests using slices.

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

The consecutive calls to Head would sometimes get different
connections depending on if the readLoop had finished executing
and placed its connection on the idle list or not.  This change
ensures that readLoop completes before we make our second connection.

Fixes #11250

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

The original version of applyRelocationsARM was added in
http://golang.org/cl/7266.  It was added to fix the ARM build, which
had been broken by http://golang.org/cl/6780.

Before CL 6780, there was no relocation processing for ARM.  CL 6780
changed the code to require relocation processing for every supported
target.  CL 7266 fixed the ARM build by adding a relocation processing
function, but in fact no actual processing was done.  The code only
looked for REL32 relocations, but ARM debug info has no such
relocations.  The test case added in CL 7266 doesn't have any either.

This didn't matter because no relocation processing was required on
ARM, at least not for GCC-generated debug info.  GCC generates ABS32
relocations, but only against section symbols which have the value 0.
Therefore, the addition done by correct handling of ABS32 doesn't
change anything.

Clang, however, generates ABS32 relocations against local symbols,
some of which have non-zero values.  For those, we need to handle
ABS32 relocations.

This patch corrects the CL 7266 to look for ABS32 relocations instead
of REL32 relocations.  The code was already written to correctly
handle ABS32 relocations, it just mistakenly said REL32.

This is the ARM equivalent of https://golang.org/cl/96680045, which
fixed the same problem in the same way for clang on 386.

With this patch, clang-3.5 can be used to build Go on ARM GNU/Linux.

Fixes #8980.

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

If an encrypted PEM block contained ciphertext that was not a multiple
of the block size then the code would panic. This change tests for that
case and returns an error.

Fixes #11215.

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

Updated the document URL in comments to avoid dead link
Old: http://www.secg.org/download/aid-780/sec1-v2.pdf
New: http://www.secg.org/sec1-v2.pdf

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

In walkdiv, an OMUL node was created and passed to typecheck,
before the op was changed back to OHMUL.  In some instances,
the node that came back was an evaluated literal constant that
occurred with a full multiply.  The end result was a literal node
with a non-shifted value and an OHMUL op. This change causes code
to be generated for the OHMUL.

Fixes #11358
Fixes #11369

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

Instrument operands of OKEY.
Also instrument OSLICESTR. Previously it was not needed
because of preceeding bounds checks (which were instrumented).
But the preceeding bounds checks have disappeared.

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

The issue was identified while
working with round trip FileInfo of the headers of hardlinks. Also,
additional test cases for hard link handling.
(review carried over from http://golang.org/cl/165860043)

Fixes #9027

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

Fixes #11402

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

Change-Id: I193b416ac91b4fa9234d30a1c1c58b3f0a71f398
Reviewed-on: https://go-review.googlesource.com/11543Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Change-Id: Ifb8e4e13c7778a7c0113190051415e096f5db94f
Reviewed-on: https://go-review.googlesource.com/11390Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Andrew Gerrand <adg@golang.org>

No need to update the date; this is not a spec change.

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

Fixes #10236

Change-Id: Ife85513efda48af81c267b753da2ac7317cdfe75
Reviewed-on: https://go-review.googlesource.com/11479Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Some old buggy browsers sent extra CRLF(s) after POST bodies. Skip
over them before reading subsequent requests.

Fixes #10876

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

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

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

At some point it silently stopped recognizing test output.
Meanwhile two tests degraded...

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

If a client sent a POST with a huge request body, calling
req.Body.Close in the handler (which is implicit at the end of a
request) would end up consuming it all.

Put a cap on that, using the same threshold used elsewhere for similar
cases.

Fixes #9662

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

Fixes #11383

Change-Id: I7ef0bb8b535ef513afdfcda19317ae4ff21f7166
Reviewed-on: https://go-review.googlesource.com/11490Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Negative width arguments now left align the way a minus-width in the
format string aligns. The minus in the format string overrides the sign
of the argument as in C.

Precision behavior is modified to include an error if the argument is
negative.  This differs from a negative precision in a format string
which just terminates the format.

Additional checks for large magnitude widths and precisions are added to
make the runtime behavior (failure, but with different error messages),
more consistent between format string specified width/precision and
argument specified width/precision.

Fixes #11376

Change-Id: I8c7ed21088e9c18128a45d4c487c5ab9fafd13ef
Reviewed-on: https://go-review.googlesource.com/11405Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>

Instead of ambiguously referring to "the Client's CheckRedirect
function" in Head, describe the default behavior like for Get as users
aren't expected to change DefaultClient.CheckRedirect.

While here, use consistent punctuation for the Get and Head Client
method documentation.

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

Just a copy, other than adding a header, preparatory to preparing the release notes.

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

Fixes #8296

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

See issue #11354.

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

The ListenAndServerTLS function still requires the certFile and
keyFile, but the Server.ListenAndServerTLS method doesn't need to
require the certFile and keyFile if the Server.TLSConfig.Certificates
are already populated.

Fixes #8599

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

Fixes #8137

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

Fixes #11379.

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

Somehow we missed this!
Fixes #11387.

Change-Id: Ida08fe52eff7da2ef7765b4cf35a39a301420c43
Reviewed-on: https://go-review.googlesource.com/11460Reviewed-by: David Chase <drchase@google.com>

For debuggers and other program inspectors.

Fixes #9914.

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

The code formatting mechanism can be applied to partial Go code,
such as a list of statements. The statements are wrapped into a
function definition (to be parsed fine), and unwrapped after formatting.

When the statements contain //line annotations, it may fail,
because not all comments are flushed by the printer before the final '}'.
Formatting "\ta()\n//line :1" results in "\ta() }\n\n//line", which
is wrong.

Tweaked the wrapping/unwrapping code to make sure comments are flushed
before the '}'.

Fixes #11276

Change-Id: Id15c80279b0382ee9ed939cca1647f525c4929f5
Reviewed-on: https://go-review.googlesource.com/11282
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

The test is flaky on builders lately. I don't see any issues other than
usage of very small sleeps. So increase the sleeps. Also take opportunity
to refactor the code.
On my machine this change significantly reduces failure rate with GOMAXPROCS=2.
I can't reproduce the failure with GOMAXPROCS=1.

Fixes #10726

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

Fixes #11208

Change-Id: I35cc94129577b2a977fd35aafb0a5fb02c534a7c
Reviewed-on: https://go-review.googlesource.com/11414Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

To date, the behavior has depended on whether we're using cgo and
in turn what the host resolver does. Most host resolvers will "resolve"
IP addresses, but the non-cgo pure Go path has not.
This CL makes resolution of IP addresses always work, even if we're not using cgo
and even if the host resolver does not "resolve" IP addresses.

Fixes #11335.

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

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

Fixes #9637
Fixes #10120

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

Not a language change.

Fixes #11350.

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

Port of https://go-review.googlesource.com/11365

Fixes #11357.

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