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>

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

Fixes #11367.

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

When heapBitsSetType repeats a source bitmap with a scalar tail
(typ.ptrdata < typ.size), it lays out the tail upon reaching the end
of the source bitmap by simply increasing the number of bits claimed
to be in the incoming bit buffer. This causes later iterations to read
the appropriate number of zeros out of the bit buffer before starting
on the next repeat of the source bitmap.

Currently, however, later iterations of the loop continue to read bits
from the source bitmap *regardless of the number of bits currently in
the bit buffer*. The bit buffer can only hold 32 or 64 bits, so if the
scalar tail is large and the padding bits exceed the size of the bit
buffer, the read from the source bitmap on the next iteration will
shift the incoming bits into oblivion when it attempts to put them in
the bit buffer. When the buffer does eventually shift down to where
these bits were supposed to be, it will contain zeros. As a result,
words that should be marked as pointers on later repetitions are
marked as scalars, so the garbage collector does not trace them. If
this is the only reference to an object, it will be incorrectly freed.

Fix this by adding logic to drain the bit buffer down if it is large
instead of reading more bits from the source bitmap.

Fixes #11286.

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

h_spans can be accessed concurrently without synchronization from
other threads, which means it needs the appropriate memory barriers on
weakly ordered machines. It happens to already have the necessary
memory barriers because all accesses to h_spans are currently
protected by the heap lock and the unlocks happen in exactly the
places where release barriers are needed, but it's easy to imagine
that this could change in the future. Document the fact that we're
depending on the barrier implied by the unlock.

Related to issue #9984.

Change-Id: I1bc3c95cd73361b041c8c95cd4bb92daf8c1f94a
Reviewed-on: https://go-review.googlesource.com/11361Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Port of https://go-review.googlesource.com/11344 to std repo.

Fixes #11325.

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

There are two conditions to worry about:

1) The shift count cannot be negative. Since the evaluator uses unsigned
arithmetic throughout, this means checking that the high bit of
the shift count is always off, which is done by converting to int64
and seeing if the result is negative.

2) For right shifts, the value cannot be negative. We don't want a
high bit in the value because right shifting a value depends on the
sign, and for clarity we always want unsigned shifts.

Next step is to build some testing infrastructure for the parser.

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

It was otherwise not being preserved across
specific Decode->Encode->Decode calls.

Fixes #11287

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

Documentation change only.

Fixes #11247.

Change-Id: Ib412de2d643292dbe42b56dee955bdb877aee81b
Reviewed-on: https://go-review.googlesource.com/11329Reviewed-by: David Symonds <dsymonds@golang.org>