Upstream PRs: https://github.com/google/pprof/pull/305,
https://github.com/google/pprof/pull/306.

Change-Id: I28969118f52ee08fcaf3572ad5da015ae756fd7a
Reviewed-on: https://go-review.googlesource.com/90935
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Also close </li> tags.

Fixes #23614

Change-Id: Icabcd577ef7df43e54d2b0068ee54614ba65bea1
Reviewed-on: https://go-review.googlesource.com/90815Reviewed-by: Cherry Zhang <cherryyz@google.com>

Executing

$ go tool dist test -run=^go_test:cmd/fix$

leaves a number of directories (fix_cgo_typecheck*) in TMPDIR.

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

Updates #22912
Fixes #23610

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

For example, the following program is valid:

	func main() {
		fmt.Printf("%[1]d", 1, 2, 3)
	}

If any of the formats are indexed, fmt will not complain about unused
extra arguments. See #22867 for more detail.

Make vet follow the same logic, to avoid erroring on programs that would
run without fmt complaining.

Fixes #23564.

Change-Id: Ic9dede5d4c37d1cd4fa24714216944897b5bb7cc
Reviewed-on: https://go-review.googlesource.com/90495
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

vet was quiet for []stringer, but not for [N]stringer. The source of the
problem was how the recursive call used .Elem().Underlying() for arrays,
but .Elem() for slices. In the first case, the named type is dropped,
thus losing all information of attached methods.

Be consistent across slices and arrays, by dropping the Underlying call
that is causing trouble. Add regression tests too, including cases where
the element type does not implement fmt.Stringer.

Fixes #23552.

Change-Id: I0fde07d101f112d5768be0a79207ef0b3dc45f2e
Reviewed-on: https://go-review.googlesource.com/90455
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

vet recorded what types had String methods defined on them, but it did
not record whether the receivers were pointer types. That information is
important, as the following program is valid:

	type T string

	func (t *T) String() string {
		return fmt.Sprint(&t) // prints address
	}

Teach vet that, if *T is Stringer, **T is not.

Fixes #23550.

Change-Id: I1062e60e6d82e789af9cca396546db6bfc3541e8
Reviewed-on: https://go-review.googlesource.com/90417
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

The problem is that vet complains about 0 as a Printf flag in some
situations where fmt allows it but probably shouldn't. The two
need to be brought in line, but it's too late in the release cycle.

The situation is messy and should be resolved properly in 1.11. This
CL is a simple fix to disable a spurious complaint for 1.10 that will be
resolved in a more thorough way in 1.11.

The workaround is just to be silent about flag 0, as suggested in
issue 23605.

Fixes #23605
Update #23498

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

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

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

CL 13166, CL 13342 and CL 33425 skipped external tests
on freebsd/arm, linux/arm and linux/mips.

This CL does the same for plan9/arm to reduce test time
on plan9/arm and prevent the Go builder to time out.

Change-Id: I16fcc5d8010a354f480673b8c4a8a11dbc833557
Reviewed-on: https://go-review.googlesource.com/90416
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

Fixes #23570.

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

recover determines whether it's being called by a deferred frame by
matching its caller's argument frame pointer with the one recorded in
the panic object. That means its caller needs a valid and unique
argument frame pointer, so it must not be inlined.

With this fix, test/recover.go passes with -l=4.

Fixes #23557.

Change-Id: I1f32a624c49e387cfc67893a0829bb248d69c3d4
Reviewed-on: https://go-review.googlesource.com/90035
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Previously we allowed drivers to modify the row buffer used to scan
values when closing Rows. This is no longer acceptable and can lead
to data races.

Fixes #23519

Change-Id: I91820a6266ffe52f95f40bb47307d375727715af
Reviewed-on: https://go-review.googlesource.com/89936
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

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

Provide a fresh conversion table for TestConversions as it gets
modified on each test.

Change-Id: I6e2240d0c3455451271a6879e994b82222c3d44c
Reviewed-on: https://go-review.googlesource.com/89595
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

In Plan 9, each OS thread has its own independent working directory,
so the Go runtime for Plan 9 needs to coordinate Chdir and Getwd
operations to keep the working directory consistent for all goroutines.

The function os.Getwd in Plan 9 should always call syscall.Getwd
to retrieve the common working directory.  Failure to do this was
the cause of (at least some of) the intermittent failures in the
Plan 9 builders with a seemingly spurious "file does not exist"
message, when a thread's working directory had been removed in
another thread.

Change-Id: Ifb834ad025ee39578234ad3b04d08bc98e939291
Reviewed-on: https://go-review.googlesource.com/89575Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

If you use -coverpkg=all you get coverage for all packages in the build.
Go 1.9 used a global counter for all the GoCover variables, so that they
were distinct for the entire build. The global counter caused problems
with caching, so we switched to a per-package counter. But now the
GoCover_0 in one package may be dot-imported into another and
conflict with the GoCover_0 in that other package.

Reestablish (overwhelmingly likely) global uniqueness of GoCover
variables by appending an _xxxxxxxxxxxx suffix, where the x's are
the prefix of the SHA256 hash of the import path. The point is only
to avoid accidents, not to defeat people determined to break the tools.

Fixes #23432.

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

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

pprof expects the samples are scaled and reflects unsampled numbers.
The legacy profile parser uses the sampling period in the output
and multiplies all values with the period.

https://github.com/google/pprof/blob/0138a3cd6dad6f94495ba0b5c3a5c124f04ae011/profile/legacy_profile.go#L815

Apply the same scaling when we output the mutex profile
in the pprof proto format.

Block profile shares the same code, but how to infer unsampled
values is unclear. Legacy profile parser doesn't do anything special
so we do nothing for block profile here.

Tested by checking the profiles reported with debug=0 (proto format)
are similar to the profiles computed from legacy format profile
when the profile rate is a non-trivial number (e.g. 2) manually.

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

Remove leading space at the beginning of error strings,
so the strings are consistent between isExist, isNotExist
and isPermission functions.

Here is a list of error strings returned on the most common
file servers on Plan 9:

     match                     cwfs                      fossil                   ramfs

"exists"            "create/wstat -- file exists"  "file already exists"    "file exists"
"is a directory"                                   "is a directory"         "file is a directory"

"does not exist"                                   "file does not exist"    "file does not exist"
"not found"         "directory entry not found"
"has been removed"                                 "file has been removed"

"permission denied" "access permission denied"     "permission denied"      "permission denied"

"no parent" is an error returned by lib9p when removing a file without parent.

Change-Id: I2362ed4b6730b8bec7a707a1052bd1ad8921cd97
Reviewed-on: https://go-review.googlesource.com/89315Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Starting on or about the 2018c archives, www.iana.org is redirected to
data.iana.org.  Tell curl to follow the redirect.

Updates: #22487

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

The compiler allows code to have multiple differently-typed views of a
single argument. For instance, if we have

func f(x float64) {
   y := *(*int64)(unsafe.Pointer(&x))
   ...
}

Then in SSA we get two OpArg ops, one with float64 type and one with
int64 type.

The compiler will try to reuse argument slots for spill slots. It
checks that the argument slot is dead by consulting an interference
graph.

When building the interference graph, we normally ignore cross-type
edges because the values on either end of that edge can't be allocated
to the same slot. (This is just a space-saving optimization.) This
rule breaks down when one of the values is an argument, because of the
multiple views described above. If we're spilling a float64, it is not
enough that the float64 version of x is dead; the int64 version of x
has to be dead also.

Remove the optimization of not recording interference edges if types
don't match. That optimization is incorrect if one of the values
connected by the edge is an argument.

Fixes #23522

Change-Id: I361f85d80fe3bc7249014ca2c3ec887c3dc30271
Reviewed-on: https://go-review.googlesource.com/89335
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

- Don't complain about invalid constant type if the type is
  invalid already (we do this in other places as well). This
  is useful to do in general, and even more so if we have
  invalid types due to import "C".

- Type-check the lhs of an assignment even if we bail out early
  due to an error on the rhs. This was simply an oversight. We
  already have machinery in place to "use" expressions; in this
  case we just have to also make sure we don't overcount "uses"
  of variables on the lhs.

- Fix overcount uses correction in assignments: Only do it if
  the variable in question is declared inside the same package
  to avoid possible race conditions when type-checking exported
  variables concurrently.

Fixes #22090.

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

Currently, startpanic_m (which prepares for an unrecoverable panic)
goes out of its way to make it possible to allocate during panic
handling by allocating an mcache if there isn't one.

However, this is both potentially dangerous and unnecessary.
Allocating an mcache is a generally complex thing to do in an already
precarious situation. Specifically, it requires obtaining the heap
lock, and there's evidence that this may be able to deadlock (#23360).
However, it's also unnecessary because we never allocate from the
unrecoverable panic path.

This didn't use to be the case. The call to allocmcache was introduced
long ago, in CL 7388043, where it was in preparation for separating Ms
and Ps and potentially running an M without an mcache. At the time,
after calling startpanic, the runtime could call String and Error
methods on panicked values, which could do anything including
allocating. That was generally unsafe even at the time, and CL 19792
fixed this be pre-printing panic messages before calling startpanic.
As a result, we now no longer allocate after calling startpanic.

This CL not only removes the allocmcache call, but goes a step further
to explicitly disallow any allocation during unrecoverable panic
handling, even in situations where it might be safe. This way, if
panic handling ever does an allocation that would be unsafe in unusual
circumstances, we'll know even if it happens during normal
circumstances.

This would help with debugging #23360, since the deadlock in
allocmcache is currently masking the real failure.

Beyond all.bash, I manually tested this change by adding panics at
various points in early runtime init, signal handling, and the
scheduler to check unusual panic situations.

Change-Id: I85df21e2b4b20c6faf1f13fae266c9339eebc061
Reviewed-on: https://go-review.googlesource.com/88835
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently, if a _SigPanic signal arrives in a throwsplit context,
nothing is stopping the runtime from injecting a call to sigpanic that
may attempt to grow the stack. This will fail and, in turn, mask the
real problem.

Fix this by checking for throwsplit in the signal handler itself
before injecting the sigpanic call.

Updates #21431, where this problem is likely masking the real problem.

Change-Id: I64b61ff08e8c4d6f6c0fb01315d7d5e66bf1d3e2
Reviewed-on: https://go-review.googlesource.com/87595
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

When we introduced the notion of alias type declarations, we renamed
"named type" to "defined type" to avoid confusion with types denoted
by aliases and thus are also types with names, or "named types".

Some of the old uses of "named types" remained; this change removes
them.

Now the spec consistently uses the terms:

- "defined type"  for a type declared via a type definition
- "type name"     for any name denoting an (alias or defined) type
- "alias"         for a type name declared in an alias declaration

New prose is encouraged to avoid the term "named type" to counter-
act further confusion.

Fixes #23474.

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

The current code misassembles VLD1/VST1 instruction with non-zero
offset. The offset is dropped silently without any error message.
The cause of the misassembling is the current code treats argument
(Rn)(Rm) as ZOREG type.

The fix changes the matching rules and considers (Rn)(Rm) as ROFF
type. The fix will report error information when assembles VLD1/VST1
(R8)(R13), [V1.16B].
The fix enables the ARM64Errors test.

Fixes #23448

Change-Id: I3dd518b91e9960131ffb8efcb685cb8df84b70eb
Reviewed-on: https://go-review.googlesource.com/87956Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Except for removing the DRAFT marker, I think these are now ready to go.

Change-Id: I20604f5b135616189a24990db463c7bb5e7d48f1
Reviewed-on: https://go-review.googlesource.com/88975
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This error is returned by os.Mkdir when the directory already exists.

This change fixes some upspin tests.

Change-Id: I9ad5aefebb32dff577726d537b4f3826d79868eb
Reviewed-on: https://go-review.googlesource.com/88656Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

When there is no go directory inside the swiglib directory then swig
was installed without Go support. Tests in misc/swig will fail when
swig is installed without Go support.

Add additional checks for the presence of a go directory in the directory
reported by 'swig -go -swiglib' to determine if misc/swig tests should
be run.

This avoids all.bash failing when swig but not swig-go is installed
using macports.

Tested on darwin with swig and with and without swig-go installed
using macports.

Fixes #23469

Change-Id: I173201221554982ea0d9f2bea70a3cb85b297cec
Reviewed-on: https://go-review.googlesource.com/88776Reviewed-by: David Chase <drchase@google.com>

Update golang/go#23515

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

In earlier versions of Go the "go vet" command would run on regular
source files and test files. That was lost in CL74750.  Bring it back.

This required moving a chunk of code from internal/test to
internal/load. The diff looks big but the code is unchanged.

Fixes #23395

Change-Id: Ie9ec183337e8db81c5fc421d118a22b351b5409e
Reviewed-on: https://go-review.googlesource.com/87636
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently, if anything goes wrong when printing a traceback, we simply
cut off the traceback without any further diagnostics. Unfortunately,
right now, we have a few issues that are difficult to debug because
the traceback simply cuts off (#21431, #23484).

This is an attempt to improve the debuggability of traceback failure
by printing a diagnostic message plus a hex dump around the failed
traceback frame when something goes wrong.

The failures look like:

goroutine 5 [running]:
runtime: unexpected return pc for main.badLR2 called from 0xbad
stack: frame={sp:0xc42004dfa8, fp:0xc42004dfc8} stack=[0xc42004d800,0xc42004e000)
000000c42004dea8:  0000000000000001  0000000000000001
000000c42004deb8:  000000c42004ded8  000000c42004ded8
000000c42004dec8:  0000000000427eea <runtime.dopanic+74>  000000c42004ded8
000000c42004ded8:  000000000044df70 <runtime.dopanic.func1+0>  000000c420001080
000000c42004dee8:  0000000000427b21 <runtime.gopanic+961>  000000c42004df08
000000c42004def8:  000000c42004df98  0000000000427b21 <runtime.gopanic+961>
000000c42004df08:  0000000000000000  0000000000000000
000000c42004df18:  0000000000000000  0000000000000000
000000c42004df28:  0000000000000000  0000000000000000
000000c42004df38:  0000000000000000  000000c420001080
000000c42004df48:  0000000000000000  0000000000000000
000000c42004df58:  0000000000000000  0000000000000000
000000c42004df68:  000000c4200010a0  0000000000000000
000000c42004df78:  00000000004c6400  00000000005031d0
000000c42004df88:  0000000000000000  0000000000000000
000000c42004df98:  000000c42004dfb8  00000000004ae7d9 <main.badLR2+73>
000000c42004dfa8: <00000000004c6400  00000000005031d0
000000c42004dfb8:  000000c42004dfd0 !0000000000000bad
000000c42004dfc8: >0000000000000000  0000000000000000
000000c42004dfd8:  0000000000451821 <runtime.goexit+1>  0000000000000000
000000c42004dfe8:  0000000000000000  0000000000000000
000000c42004dff8:  0000000000000000
main.badLR2(0x0)
	/go/src/runtime/testdata/testprog/badtraceback.go:42 +0x49

For #21431, #23484.

Change-Id: I8718fc76ced81adb0b4b0b4f2293f3219ca80786
Reviewed-on: https://go-review.googlesource.com/89016
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

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

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

On an android/amd64 emulator, $HOME points to / which is not writable.
Ignore the error in the pprof driver test.

With this, androidtest.sh on android/amd64 and android/386 passes.

Upstream pull request https://github.com/google/pprof/pull/295.

Change-Id: If919d7f44530a977fd044631ad01bac87d32deaa
Reviewed-on: https://go-review.googlesource.com/88817
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

Change-Id: I14eeda85f279d1082ea9f2ac590b848ac13b1daa
Reviewed-on: https://go-review.googlesource.com/87023
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Fix breakage introduced in CL 70530.

Change-Id: I87f3da6b20554d4f405a1143b0d894c5953b63aa
Reviewed-on: https://go-review.googlesource.com/88516
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>