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>

This appears to be some legacy which is no longer used.

Change-Id: I469beb59a90853e8de910158f179b32f1aa14c7d
Reviewed-on: https://go-review.googlesource.com/11304Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>

Some of those consts were supposed to be vars.

Caught by Ingo Oeser.

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

The change that "fixed" LSH was incorrect, and the fix for RSH was poor.
Make both use a correct, simple test: if the 64-bit value as a signed
integer is negative, it's an error.

Really fixes #11278.

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

And vice versa.

The flags are tightly coupled so make the connection clear.

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

This CL removes the single and racy use of mheap.arena_end outside
of the bookkeeping done in mHeap_init and mHeap_Alloc.
There should be no way for heapBitsForSpan to see a pointer to
an invalid span. This CL makes the check for this more precise by
checking that the pointer is between mheap_.arena_start and
mheap_.arena_used instead of mheap_.arena_end.

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

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

In order to avoid a race with a concurrent write barrier or garbage
collector thread, any update to arena_used must be preceded by mapping
the corresponding heap bitmap and spans array memory. Otherwise, the
concurrent access may observe that a pointer falls within the heap
arena, but then attempt to access unmapped memory to look up its span
or heap bits.

Commit d57c889a fixed all of the places where we updated arena_used
immediately before mapping the heap bitmap and spans, but it missed
the one place where we update arena_used and depend on later code to
update it again and map the bitmap and spans. This creates a window
where the original race can still happen. This commit fixes this by
mapping the heap bitmap and spans before this arena_used update as
well. This code path is only taken when expanding the heap reservation
on 32-bit over a hole in the address space, so these extra mmap calls
should have negligible impact.

Fixes #10212, #11324.

Change-Id: Id67795e6c7563eb551873bc401e5cc997aaa2bd8
Reviewed-on: https://go-review.googlesource.com/11340
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

The unsynchronized accesses to mheap_.arena_used in the concurrent
part of the garbage collector look like a problem waiting to happen.
In fact, they are safe, but the reason is somewhat subtle and
undocumented. This commit documents this reasoning.

Related to issue #9984.

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

Historically we have declined to try to provide real support for URLs
that contain %2F in the path, but they seem to be popping up more
often, especially in (arguably ill-considered) REST APIs that shoehorn
entire paths into individual path elements.

The obvious thing to do is to introduce a URL.RawPath field that
records the original encoding of Path and then consult it during
URL.String and URL.RequestURI. The problem with the obvious thing
is that it breaks backward compatibility: if someone parses a URL
into u, modifies u.Path, and calls u.String, they expect the result
to use the modified u.Path and not the original raw encoding.

Split the difference by treating u.RawPath as a hint: the observation
is that there are many valid encodings of u.Path. If u.RawPath is one
of them, use it. Otherwise compute the encoding of u.Path as before.

If a client does not use RawPath, the only change will be that String
selects a different valid encoding sometimes (the original passed
to Parse).

This ensures that, for example, HTTP requests use the exact
encoding passed to http.Get (or http.NewRequest, etc).

Also add new URL.EscapedPath method for access to the actual
escaped path. Clients should use EscapedPath instead of
reading RawPath directly.

All the old workarounds remain valid.

Fixes #5777.
Might help #9859.
Fixes #7356.
Fixes #8767.
Fixes #8292.
Fixes #8450.
Fixes #4860.
Fixes #10887.
Fixes #3659.
Fixes #8248.
Fixes #6658.
Reduces need for #2782.

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

The test was translated from shell incorrectly,
and it depended on having hg installed, which
may not be the case.

Moved repo to GitHub, updated code, and fixed
go list ... command to be expected to succeed.

Fixes test for #8181.

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

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

In the parser, the shift value is always a uint64.

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

A header of ": value" results in an empty key. Do not add
it to the headers, because RFC7230 (section 3.2) says that
field-names are tokens, which are one or more characters.

Fixes #11205.

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

Fixes #11278.

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

Most important: skip test on darwin/arm64 for unclear reasons.

First cut at the test missed this feature of go doc: when asking for
the docs for a type, include any function that looks like it constructs
a that type as a return value.

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