Replaces CL 33356.

Fixes #17262.

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

This fixes a bug in -l=3 or higher.

To inline a variadic function, the compiler generates code that constructs
a slice of arguments for the variadic parameter. Consider the function

  func Foo(xs ...string)

and the call Foo("hello", "world"). To inline the call to Foo, the
compiler used to generate

  xs := [2]string{"hello", "world"}[:]

which doesn't type check:

  invalid operation [2]string literal[:] (slice of unaddressable value).

Now, the compiler generates

  xs := []string{"hello", "world"}

which does type check.

Fixes #18116.

Change-Id: I0ee531ef2e6cc276db6fb12602b25a46d6d5db21
Reviewed-on: https://go-review.googlesource.com/33671Reviewed-by: Keith Randall <khr@golang.org>

And fix a bad link.

TBR=See https://golang.org/cl/33244

Updates #17929

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

Rather then using a sleep in the fake DB, go to a channel
select and wait for the context to be done.

Fixes #18115

Change-Id: I6bc3a29db58c568d0a7ea06c2a354c18c9e798b2
Reviewed-on: https://go-review.googlesource.com/33712
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

From the garbage collector's perspective, time can move backwards in
cgocall. However, in the midst of this time warp, the pointer
arguments to cgocall can go from dead back to live. If a stack growth
happens while they're dead and then a GC happens when they become live
again, GC can crash with a bad heap pointer.

Specifically, the sequence that leads to a panic is:

1. cgocall calls entersyscall, which saves the PC and SP of its call
site in cgocall. Call this PC/SP "X". At "X" both pointer arguments
are live.

2. cgocall calls asmcgocall. Call the PC/SP of this call "Y". At "Y"
neither pointer argument is live.

3. asmcgocall calls the C code, which eventually calls back into the
Go code.

4. cgocallbackg remembers the saved PC/SP "X" in some local variables,
calls exitsyscall, and then calls cgocallbackg1.

5. The Go code causes a stack growth. This stack unwind sees PC/SP "Y"
in the cgocall frame. Since the arguments are dead at "Y", they are
not adjusted.

6. The Go code returns to cgocallbackg1, which calls reentersyscall
with the recorded saved PC/SP "X", so "X" gets stashed back into
gp.syscallpc/sp.

7. GC scans the stack. It sees there's a saved syscall PC/SP, so it
starts the traceback at PC/SP "X". At "X" the arguments are considered
live, so it scans them, but since they weren't adjusted, the pointers
are bad, so it panics.

This issue started as of commit ca4089ad, when the compiler stopped
marking arguments as live for the whole function.

Since this is a variable liveness issue, fix it by adding KeepAlive
calls that keep the arguments live across this whole time warp.

The existing issue7978 test has all of the infrastructure for testing
this except that it's currently up to chance whether a stack growth
happens in the callback (it currently only happens on the
linux-amd64-noopt builder, for example). Update this test to force a
stack growth, which causes it to fail reliably without this fix.

Fixes #17785.

Change-Id: If706963819ee7814e6705693247bcb97a6f7adb8
Reviewed-on: https://go-review.googlesource.com/33710Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Change-Id: I9f2c2da4aa512729ae40562b06601da95ba50d6f
Reviewed-on: https://go-review.googlesource.com/33689Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Be consistent with the argument names already provided. Also
parameter is the variable, argument is the value.

Fixes #18099

Change-Id: Idb3f4e9ffc214036c721ddb4f614ec6c95bb7778
Reviewed-on: https://go-review.googlesource.com/33660
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #18096

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

TBR=See https://golang.org/cl/33244

Updates #18095

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

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

Mutex profiling, syscall, fmt, go/types, html/template.

TBR=See https://golang.org/cl/33244

Updates #17929

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

TBR=See https://golang.org/cl/33244

Updates #17929

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

The code was intended to test that mux handler should redirect at
most once, but the added loop condition defeated that. Remove the
loop condition and document the intention better.

Fixes #18068.

Change-Id: I2a4ea041eae27168b45a09aa46e740ac03921594
Reviewed-on: https://go-review.googlesource.com/33654
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Some still in TODO form.

TBR=See https://golang.org/cl/33244

Updates #17929

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

TBR=See https://golang.org/cl/33244

Updates #17929

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

And start deleting from go1.8.txt.

TBR=See https://golang.org/cl/33244

Updates #17929

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

None of them need to be called out in the release notes.

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

As discussed in #18095 the server should not log for bad user input.

Change-Id: I628a796926eff3a971e5b04abec17ea377c3f9b7
Reviewed-on: https://go-review.googlesource.com/33617Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I01b2278eb50585331b8ff7ff5e3c1f9c5ba52b63
Reviewed-on: https://go-review.googlesource.com/33156Reviewed-by: Matthew Dempsky <mdempsky@google.com>

TBR=See https://golang.org/cl/33244

Updates #17929

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

Fixes #18109.

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

Expand myhostname fallback detection to properly detect the local
hostname in addition to other supported special names and suffixes.

Fixes #17967

Change-Id: I1fe141fd9838b25886c08b6f2fd325e58be60457
Reviewed-on: https://go-review.googlesource.com/33550Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

TBR=See https://golang.org/cl/33244

Updates #17929

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

TBR=See https://golang.org/cl/33244

Updates #17929

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

Some countermeasures were implemented in https://golang.org/cl/18130

Updates #13385

Change-Id: I723e1e3be0fa6d13767b65b145d90c89e92b2774
Reviewed-on: https://go-review.googlesource.com/33665Reviewed-by: Adam Langley <agl@golang.org>

Adds crypto/tls, crypto/x509, math/big, mime.

TBR=See https://golang.org/cl/33244

Updates #17929

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

TBR=See https://golang.org/cl/33244

Updates #17929

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

The doc field is not yet used - remove it for now (we may end up
with a different solution for 1.9). This reduces memory consumption
for parsing all of std lib by about 40MB and makes parsing slightly
faster.

Change-Id: Iafb00b9c7f1be9c66fdfb29096d3da5049b2fcf5
Reviewed-on: https://go-review.googlesource.com/33661Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

When context methods were initially added it was attempted to unify
behavior between drivers without Context methods and those with
Context methods to always return right away when the Context expired.
However in doing so the driver call could be executed outside of the
scope of the driver connection lock and thus bypassing thread safety.

The new behavior waits until the driver operation is complete. It then
checks to see if the context has expired and if so returns that error.

Change-Id: I4a5c7c3263420c57778f36a5ed6fa0ef8cb32b20
Reviewed-on: https://go-review.googlesource.com/32422Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Also refactor common position filling code into a function.

Fixes #18011

Change-Id: I76528626da67a7309193fa92af1e361c8e2fcf84
Reviewed-on: https://go-review.googlesource.com/33631
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Skip lines if they are empty or starting with "#" which are valid
legacy pprof output format.

Fixes #18025

Change-Id: I7aee439171496932637b8ae3188700911f569b16
Reviewed-on: https://go-review.googlesource.com/33454Reviewed-by: Peter Weinberger <pjw@google.com>

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

Fixes #18092.

Change-Id: I54e2da2e0f168c068f5e4a1b22ba508d78259168
Reviewed-on: https://go-review.googlesource.com/33658
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Android's libc doesn't provide access to auxv, so currently the Go
runtime synthesizes a fake, minimal auxv when loaded as a library on
Android. This used to be sufficient, but now we depend on auxv to
retrieve the system physical page size and panic if we can't retrieve
it.

Fix this by falling back to reading auxv from /proc/self/auxv if the
loader-provided auxv is empty and removing the synthetic auxv vectors.

Fixes #18041.

Change-Id: Ia2ec2c764a6609331494a5d359032c56cbb83482
Reviewed-on: https://go-review.googlesource.com/33652
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

This refactoring is in preparation for handling auxv differently in
Android shared libraries.

Updates #18041.

Change-Id: If0458a309f9c804e7abd0a58b5a224d89f8da257
Reviewed-on: https://go-review.googlesource.com/33651
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

TBR=See https://golang.org/cl/33244

Updates #17929

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

Address Russ's feedback from https://golang.org/cl/33244

TBR=See https://golang.org/cl/33244

Updates #17929

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

Tested by running

GOTRACEBACK=2 CGO_CFLAGS="-Wa,--elf-stt-common=yes" go test -ldflags=-linkmode=internal

in misc/cgo/test. That failed before this CL, succeeded after.

I don't think it's worth doing that as a regular test, though,
especially since only recent versions of the GNU binutils support the
--elf-stt-common option.

Fixes #18088.

Change-Id: I893d86181faee217b1504c054b0ed3f7c8d977d3
Reviewed-on: https://go-review.googlesource.com/33653
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.

The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.

Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.

	package main

	import (
	    "fmt"
	    "os"
	)

	func main() {
	    p := make([]byte, 100)
	    fmt.Printf("> ")
	    for {
	        n, err := os.Stdin.Read(p)
	        fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
	    }
	}

On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:

	$ go run /tmp/x.go
	> hello
	[6 "hello\n" <nil>]
	> hello^D[5 "hello" <nil>]
	> ^D[0 "" EOF]
	> ^D[0 "" EOF]
	> hello^Dworld
	[5 "hello" <nil>]
	> [6 "world\n" <nil>]
	>

On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:

	C:\>c:\go1.5.4\bin\go run x.go
	> ^Z
	[3 "\x1a\r\n" <nil>]
	> hello^Zworld
	[13 "hello\x1aworld\r\n" <nil>]
	>

CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:

	C:\>c:\go1.6.3\bin\go run x.go
	> ^Z
	[0 "" EOF]
	> hello^Zworld
	[13 "hello\x1aworld\r\n" <nil>]
	>

So the fix was incomplete.
Worse, the fix broke Unicode console input.

ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:

	C:\>c:\go1.5.4\bin\go run x.go
	> hello
	[7 "hello\r\n" <nil>]
	> hello world™
	[16 "hello world™\r\n" <nil>]
	>

But in Go 1.6:

	C:\>c:\go1.6.3\bin\go run x.go
	> hello
	[7 "hello\r\n" <nil>]
	> hello world™
	[0 "" EOF]
	>

That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)

CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.

CL 29493 also broke ^Z handling, which was filed as #17427.

This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)

With this CL:

	C:\>go run x.go
	> hello
	[7 "hello\r\n" <nil>]
	> hello world™
	[16 "hello world™\r\n" <nil>]
	> ^Z
	[0 "" EOF]
	> [2 "\r\n" <nil>]
	> hello^Zworld
	[5 "hello" <nil>]
	> [0 "" EOF]
	> [7 "world\r\n" <nil>]

This almost matches Unix:

	$ go run /tmp/x.go
	> hello
	[6 "hello\n" <nil>]
	> hello world™
	[15 "hello world™\n" <nil>]
	> ^D
	[0 "" EOF]
	> [1 "\n" <nil>]
	> hello^Dworld
	[5 "hello" <nil>]
	> [6 "world\n" <nil>]
	>

The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.

On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:

	C:\>copy con x.txt
	hello^Zworld
	        1 file(s) copied.

	C:\>type x.txt
	hello
	C:\>

A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.

Fixes #17427.
Fixes #17939.

Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes the os test on the Android builder.

Change-Id: Ibb9db712156a620fcccf515e035475c5e2f535a5
Reviewed-on: https://go-review.googlesource.com/33650
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>