cmd/go sometimes returns relative path in the error message
(see shortPath function). Account for that during
TestFileLineInErrorMessages.

Fixes #11355

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

- Let runOutput return the error message
- When `git config ...` returns empty buffer, it means the config key is
  correct, but there is no corresponding value.
- Return the correct error when the url of remote origin is not found.
- Update error message

Fixes: #10922

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

Linux allows to have a peer IP address on IP interface over ethernet
link encapsulation, though it only installs a static route with the peer
address as an on-link nexthop.

Fixes #11338.

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

Also add a couple more errors, such as modulo with a zero divisor.

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

Update #11426

Change-Id: I7abc4ed2241a7a3af6d57c934786f36de4f97b77
Reviewed-on: https://go-review.googlesource.com/11592
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes the build from https://golang.org/cl/4117 (sync: simplify WaitGroup)

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

Currently, to write out the bitmap of a slice of a type with a GCprog,
we construct a new GCprog that executes the underlying type's GCprog
to write out the bitmap once and then repeats those bits n more times.
This results in n+1 repetitions of the bitmap, which is one more
repetition than it should be. This corrupts the bitmap of the heap
following the slice and may write past the mapped bitmap memory and
segfault.

Fix this by repeating the bitmap only n-1 more times.

Fixes #11430.

Change-Id: Ic24854363bffc5a755b66f257339f9309ada3aa5
Reviewed-on: https://go-review.googlesource.com/11570
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

Update #11426

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

These tests pass after cl/11417.

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

A comment in waitgroup.go describes the following scenario
as the reason to have dynamically created semaphores:

// G1: Add(1)
// G1: go G2()
// G1: Wait() // Context switch after Unlock() and before Semacquire().
// G2: Done() // Release semaphore: sema == 1, waiters == 0. G1 doesn't run yet.
// G3: Wait() // Finds counter == 0, waiters == 0, doesn't block.
// G3: Add(1) // Makes counter == 1, waiters == 0.
// G3: go G4()
// G3: Wait() // G1 still hasn't run, G3 finds sema == 1, unblocked! Bug.

However, the scenario is incorrect:
G3: Add(1) happens concurrently with G1: Wait(),
and so there is no reasonable behavior of the program
(G1: Wait() may or may not wait for G3: Add(1) which
can't be the intended behavior).

With this conclusion we can:
1. Remove dynamic allocation of semaphores.
2. Remove the mutex entirely and instead pack counter and waiters
   into single uint64.

This makes the logic significantly simpler, both Add and Wait
do only a single atomic RMW to update the state.

benchmark                            old ns/op     new ns/op     delta
BenchmarkWaitGroupUncontended        30.6          32.7          +6.86%
BenchmarkWaitGroupActuallyWait       722           595           -17.59%
BenchmarkWaitGroupActuallyWait-2     396           319           -19.44%
BenchmarkWaitGroupActuallyWait-4     224           183           -18.30%
BenchmarkWaitGroupActuallyWait-8     134           106           -20.90%

benchmark                          old allocs     new allocs     delta
BenchmarkWaitGroupActuallyWait     2              1              -50.00%

benchmark                          old bytes     new bytes     delta
BenchmarkWaitGroupActuallyWait     48            16            -66.67%

Change-Id: I28911f3243aa16544e99ac8f1f5af31944c7ea3a
Reviewed-on: https://go-review.googlesource.com/4117
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #10572

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

This commit fixes a cosmetic defect whereby quick.Check reports that
the provided function returns too many values when it may, in fact,
return too few:

  func f() {}

  func TestFoo(t *testing.T) {
    if err := quick.Check(f, nil); err != nil {
      t.Fatal(err)
    }
  }
  // yields
  // $ go test -v foo_test.go
  // === RUN TestFoo
  // --- FAIL: TestFoo (0.00s)
  // 	foo_test.go:76: function returns more than one value.

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

Not sure if I'm on time for 1.5; Unicode 8 just got released.

Straighforward upgrade. Only changed maketables.go to prevent it from adding
the Cherokee upper and lower case mappings. This change causes the caseOrbit
table to NOT change. Added tests to verify that the relevant functions still
produce the correct result, even for Cherokee.

Fixes #11309

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

Updates #8154

Change-Id: Ie9c731a91b008277e51c723eef6871bb0919fa4c
Reviewed-on: https://go-review.googlesource.com/10831Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Removes the remains of the old C based stepflt implementation.
Also removed goto usage.

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

The new inlined code for append assumed that it could pass the
desired new cap to growslice, not the number of new elements.
But growslice still interpreted the argument as the number of new elements,
making it always grow by >2x (more precisely, 2x+1 rounded up
to the next malloc block size). At the time, I had intended to change
the other callers to use the new cap as well, but it's too late for that.
Instead, introduce growslice_n for the old callers and keep growslice
for the inlined (common case) caller.

Fixes #11403.

Filed #11419 to merge them.

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

Includes a new net/http test too.

Fixes #11202

Change-Id: I61edc594f4de8eb6780b8dfa221269dd482e8f35
Reviewed-on: https://go-review.googlesource.com/11492Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #11399

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

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>