Unfortunately there's no simple, easy way to make Dial{TCP,UDP} fail
consistently across all platforms. Fow now we skip the test on Solaris.

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

Fixes #10683.

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

dialSerial connects to a list of addresses in sequence.  If a
timeout is specified, then each address gets an equal fraction of the
remaining time, with a magic constant (2 seconds) to prevent
"dial a million addresses" from allotting zero time to each.

Normally, net.Dial passes the DNS stub resolver's output to dialSerial.
If an error occurs (like destination/port unreachable), it quickly skips
to the next address, but a blackhole in the network will cause the
connection to hang until the timeout elapses.  This is how UNIXy clients
traditionally behave, and is usually sufficient for non-broken networks.

The DualStack flag enables dialParallel, which implements Happy Eyeballs
by racing two dialSerial goroutines, giving the preferred family a
head start (300ms by default).  This allows clients to avoid long
timeouts when the network blackholes IPv4 xor IPv6.

Fixes #8453
Fixes #8455
Fixes #8847

Change-Id: Ie415809c9226a1f7342b0217dcdd8f224ae19058
Reviewed-on: https://go-review.googlesource.com/8768Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Id93b8ab42fa311ce32209734ec9a0813f8736e25
Reviewed-on: https://go-review.googlesource.com/9914Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

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

This is https://go-review.googlesource.com/10999 which we could not apply
in x/tools/go/types because we must not rely on 1.5 features in that repo
yet.

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

The main change is:

golang.org/cl/10800  add pos parameter to Eval; remove New, EvalNode

followed by several cleanups/follow-up fixes:

golang.org/cl/10992  remove global vars in test
golang.org/cl/10994  remove unused scope parameter from NewSignature
golang.org/cl/10995  provide full source file extent to file scope
golang.org/cl/10996  comment fix in resolver.go
golang.org/cl/11004  updated cmd/vet
golang.org/cl/11042  be robust in the presence of incorrect/missing position info

Fixes #9980.

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

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

The problem was not the kernel version as I thought before, it was
that the test used the same number for both the UID and the GID.
Thanks to Chris Siebenmann for debugging this.

Fixes #11220.

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

This CL adds a very long comment explaining how isStale and
the new build IDs work. As part of writing the comment I realized:

// When the go command makes the wrong build decision and does not
// rebuild something it should, users fall back to adding the -a flag.
// Any common use of the -a flag should be considered prima facie evidence
// that isStale is returning an incorrect false result in some important case.
// Bugs reported in the behavior of -a itself should prompt the question
// ``Why is -a being used at all? What bug does that indicate?''

The two uses of -a that are most commonly mentioned in bugs filed
against the go command are:

	go install -a ./...
	go build -tags netgo -a myprog

Both of these commands now do the right thing without needing -a.

The -a exception we introduced in Go 1.4 was for the first form, and
it broke the second form. Again, neither needs -a anymore, so restore
the old, simpler, easier to explain, less surprising meaning used in Go 1.3:
if -a is given, rebuild EVERYTHING.

See the comment for more justification and history.

Summary of recent CLs (to link bugs to this one):

Fixes #3036. Now 'go install ./...' works.
Fixes #6534. Now 'go install ./...' works.
Fixes #8290. Now 'go install ./...' works.
Fixes #9369. Now 'go build -tags netgo myprog' works.
Fixes #10702. Now using one GOPATH with Go 1.5 and Go 1.6 works.
  (Each time you switch, everything needed gets rebuilt.
  Switching from Go 1.4 to Go 1.5 will rebuild properly.
  Switching from Go 1.5 back to Go 1.4 still needs -a when
  invoking the Go 1.4 go command.)

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

This causes packages and binaries built by Go 1.5 to look
out of date to Go 1.6 and vice versa, so that when you flip
between different Go versions but keep the same GOPATH,
the right rebuilding happens at each flip.

Go 1.4 binaries will also look out of date to Go 1.5,
but Go 1.5 binaries will not look out of date to Go 1.4
(since Go 1.4 doesn't have anything like this).
People flipping between Go 1.4 and Go 1.5 will still
need to use go install -a every time to flip to Go 1.4,
but not when they flip back to Go 1.5.

Fixes #6534.
Fixes #10702.

Change-Id: I0ae7f268f822d483059a938a4f22846ff9275b4c
Reviewed-on: https://go-review.googlesource.com/10760Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

A workaround for #10460.

Change-Id: I607a556561d509db6de047892f886fb565513895
Reviewed-on: https://go-review.googlesource.com/10819Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Fixes #11131

When running 'go install -buildmode=c-shared', under the circumstances
described in issue #11131, the install command would fail trying to
install cgo headers if they have already been installed (by a previous
call to 'go install -buildmode=c-shared').

Since it's safe to overwrite said headers (according to iant@), this CL
introduces a parameter to builder's 'copy' and 'move' functions that,
if set to 'true', would force the overwriting of already installed
files.

This parameter value is set to 'true' only when installing cgo headers,
for now.

Change-Id: I5bda17ee757066a8e5d2b39f2e8f3a389eb1e4a2
Reviewed-on: https://go-review.googlesource.com/10870
Run-TryBot: Srdjan Petrovic <spetrovic@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The number of CPUs is of value when benchmarking but mostly
noise when testing. The recent change to default to the number
of CPUs available has made the tests noisier and confusing.

Fixes #11200

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

Fixes #10303.

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

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

While we're here, update the documentation and delete variables with no effect.

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

A send on an unbuffered channel to a blocked receiver is the only
case in the runtime where one goroutine writes directly to the stack
of another. The garbage collector assumes that if a goroutine is
blocked, its stack contains no new pointers since the last time it ran.
The send on an unbuffered channel violates this, so it needs an
explicit write barrier. It has an explicit write barrier, but not one that
can handle a write to another stack. Use one that can (based on type bitmap
instead of heap bitmap).

To make this work, raise the limit for type bitmaps so that they are
used for all types up to 64 kB in size (256 bytes of bitmap).
(The runtime already imposes a limit of 64 kB for a channel element size.)

I have been unable to reproduce this problem in a simple test program.

Could help #11035.

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

Fixes #11201

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

Change-Id: I21cfea3eadb37904252900324c23e2664b121bbb
Reviewed-on: https://go-review.googlesource.com/11099
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #11216.

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

When reading along the article, the extra code added in the final
version is not explained. The main function calls flag.Parse(), for
example, which will cause an error, unless the readers looks at the
entirety of final.go to see the import added.

The file shown to the users no longer has the extra flags. The testing
code is now in a patch that gets applied to final.go in order to create
final-test.go. This is the file that will be used to test the code,
matching final.go as much as possible.

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

In generateTrace we check that event timestamp is within the interesting range.
Then later in traceContext.time we double check event time.
However, for some events (e.g. emitSlice) we convert time of ev.Link (slice end) rather than ev itself (slice begin).
Slice end can be outside of the interesting time range, and so traceContext.time crashes.
Remove the check in traceContext.time, check in generateTrace loop is sufficient.

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

Update to tip to fix #11003 (not possible to select events in chromium).
Fixed #11003

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

Return io.ErrUnexpectedEOF instead of io.EOF when reading a truncated
data descriptor.

Fixes #11146.

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

The previous code had a brain fart: it took one of the length prefixes
as an element count, not a length. This didn't actually affect anything
because the loop stops as soon as it finds a hostname element, and the
hostname element is always the first and only element. (No other element
types have ever been defined.)

This change fixes the parsing in case SNI is ever changed in the future.

Fixes #10793.

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

s/Backtrace/Backtrack/

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

The test fails on Ubuntu Trusty for some reason, probably because of
some set of kernel patches.

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

TBR: bradfitz, adonovan

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

Fixes #10992.

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

This was found while fuzzing another program, triggering a panic in
x509.ParseECPrivateKey.

Fixes #11154

Change-Id: Ief35ead38adf14caec4d37b9eacf8a92e67cd1e6
Reviewed-on: https://go-review.googlesource.com/10712Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>

When scanning with a width, as in %5s, C skips leading spaces
brefore counting the 5 characters. We should do the same.

Reword the documentation about widths to make this clear.

Fixes #9444

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

Running -copylocks over a large corpus generates 1507 warnings.
Of those, only 3 are from the new anonymous function check,
but they are all bugs.

Fixes #10927.

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

This is needed for code that relies on having the correct file set
when parsing an expression only. There's currently no other way to
get to the file set otherwise or to invoke the parser correctly to
work on an expression only with a given file set.

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

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

Linux 3.19 made a change in the handling of setgroups and the 'gid_map' file to
address a security issue.
The upshot of the 3.19 changes is that in order to update the 'gid_maps' file,
use of the setgroups() system call in this user namespace must first be disabled
by writing "deny" to one of the /proc/PID/setgroups files for this namespace.

Also added tests for remapping uid_map and gid_map inside new user
namespace.

Fixes #10626

Change-Id: I4d2539acbab741a37092d277e10f31fc39a8feb7
Reviewed-on: https://go-review.googlesource.com/10670
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

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

Sanity check the pax-header size field before using it.

Fixes #11167.

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

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

The documentation says that newlines behave like this:

Scan etc.: newlines are spaces.
Scanln etc.: newlines terminate the scan.
Scanf etc.: newlines must match in input and format.

The code did not implement this behavior in all cases,
especially for Scanf. Make it behave:

- Fix the handling of spaces and newlines in ss.Advance.
The code is longer but now behaves as it should.

- Delete the reuse of the current ss in newScanState.
There is really no need, since it's only used in recursive
calls to Scan etc., and the flags are likely wrong. Simpler
just to allocate a new one every time, and likelier to
be correct.

Fixes #10862.

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