Fatalf calls in two Float tests use the %s verb with Floats values,
which is not allowed and results in failure messages that look like
this:

    float_test.go:1385: i = 0, prec = 1, ToZero:
                     %!s(*big.Float=1) [0]
                /    %!s(*big.Float=1) [0]
                =    %!s(*big.Float=0.0625)
                want %!s(*big.Float=1)

Switch to %v.

Change-Id: Ifdc80bf19c91ca1b190f6551a6d0a51b42ed5919
Reviewed-on: https://go-review.googlesource.com/87199
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

ordercopyexpr is only called with 0 or 1 as value for the clear
argument. The clear variable in ordercopyexpr is only used in the
call to ordertemp which has a clear argument of type bool.

Change the clear argument of ordercopyexpr from int to bool and change
calls to ordercopyexpr to use false instead of 0 and true instead of 1.

Passes toolstash -cmp.

Change-Id: Ic264aafd3b0c8b99f6ef028ffaa2e30f23f9125a
Reviewed-on: https://go-review.googlesource.com/88115Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

This makes the constant names less verbose and aligns them more
with the Linux kernel which uses HWCAP_XXX for the constant names.

Change-Id: Ia7d079b59b57978adc045945951eaa1d99b41fac
Reviewed-on: https://go-review.googlesource.com/91738
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Also order the syscall number list by numerically for mips64x.

Follow-up for CL 92895.

Change-Id: I5f01f8c626132a06160997fce8a2aef0c486bb1c
Reviewed-on: https://go-review.googlesource.com/93616
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This moves the paragraph mentioning the use of _ higher up
to emphasize the warning and thereby reducing chances of getting
stuck.

Fixes #22617

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

Fixes #23574

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

The sub-word shifts need to sign-extend before shifting, to avoid
bringing in data from higher in the argument.

Fixes #23812

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

As usual, adding go1.11 early in the cycle so that we can start
regression testing of the master toolchain.

Change-Id: Ie96eca7223722d60d7acc6b3b996b76740c36419
Reviewed-on: https://go-review.googlesource.com/93775Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

CL 92916 added the GOMAXPROCS test in TestTraceSymbolize.

This test only succeeds when the value of GOMAXPROCS changes.

Since the test calls runtime.GOMAXPROCS(1), it will fails
on machines where GOMAXPROCS=1.

This change fixes the test by calling runtime.GOMAXPROCS(oldGoMaxProcs+1).

Fixes #23816.

Change-Id: I1183dbbd7db6077cbd7fa0754032ff32793b2195
Reviewed-on: https://go-review.googlesource.com/93735
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

It makes no sense to try to get the zero value of a nil type, hence the
panic. When we have a nil type, use reflect.ValueOf(nil) instead.

This was showing itself if one used a missing field on the data between
parentheses, when the data was a nil interface:

	t := template.Must(template.New("test").Parse(`{{ (.).foo }}`))
	var v interface{}
	t.Execute(os.Stdout, v)

Resulting in:

	panic: reflect: Zero(nil) [recovered]
		panic: reflect: Zero(nil)

Fixes #21171.

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

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

Since https://golang.org/cl/38533, this validation is performed in
driverArgs.

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

When 'convertAssign' gives an error, instead of giving just the index of
the failing column -- which is not always helpful, especially when there
are lots of columns in the query -- utilize 'rs.rowsi.Columns()' to
extract the underlying column name and include that in the error string:

    sql: Scan error on column index 0, name "some_column": ...

Fixes #23362

Change-Id: I0fe71ff3c25f4c0dd9fc6aa2c2da2360dd93e3e0
Reviewed-on: https://go-review.googlesource.com/86537Reviewed-by: Harald Nordgren <haraldnordgren@gmail.com>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The former checks if a type has a method called "Format". The latter
checks if a type satisfies fmt.Formatter.

isFormatter does exactly what we want, so it's both simpler and more
accurate. Remove the only use of hasMethod in its favor.

Change-Id: Idc156a99081c3308f98512b87011a04aa8c6638d
Reviewed-on: https://go-review.googlesource.com/91215
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

All the other tools and commands print the usage text to standard error.
"go tool compile" was the odd one out, so fix it.

While at it, make objabi.Flagprint a bit more Go-like with an io.Writer
instead of a file descriptor, which is likely a leftover from the C
days.

Fixes #23234.

Change-Id: I9abf2e79461e61c8c8bfaee2c6bf8faf26e0e6c3
Reviewed-on: https://go-review.googlesource.com/85418
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Currently, if a sigpanic call is injected into C code, it's possible
for preparePanic to leave the stack in a state where traceback can't
unwind correctly past the sigpanic.

Specifically, shouldPushPanic sniffs the stack to decide where to put
the PC from the signal context. In the cgo case, it will find that
!findfunc(pc).valid() because pc is in C code, and then it will check
if the top of the stack looks like a Go PC. However, this stack slot
is just in a C frame, so it could be uninitialized and contain
anything, including what looks like a valid Go PC. For example, in
https://build.golang.org/log/c601a18e2af24794e6c0899e05dddbb08caefc17,
it sees 1c02c23a <runtime.newproc1+682>. When this condition is met,
it skips putting the signal PC on the stack at all. As a result, when
we later unwind from the sigpanic, we'll "successfully" but
incorrectly unwind to whatever PC was in this uninitialized slot and
go who knows where from there.

Fix this by making shouldPushPanic assume that the signal PC is always
usable if we're running C code, so we always make it appear like
sigpanic's caller.

This lets us be pickier again about unexpected return PCs in
gentraceback.

Updates #23640.

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

This logic is duplicated in all of the preparePanic functions. Pull it
out into one architecture-independent function.

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

Fixes #23791

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

While doing that, establish a negative value as signal for unknown
array lengths and adjust various array-length processing code to
handle that case.

Fixes #23712.

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

The Netscape looping application extension encodes how many
times the animation should restart, and if it's present
there is no way to signal that a GIF should play only once.

Use LoopCount=-1 to signal when a decoded GIF had no looping
extension, and update the encoder to omit that extension
block when LoopCount=-1.

Fixes #15768

GitHub-Last-Rev: 249744f0e28ef8907aa876070a102cb5493f5084
GitHub-Pull-Request: golang/go#23761
Change-Id: Ic915268505bf12bdad690b59148983a7d78d693b
Reviewed-on: https://go-review.googlesource.com/93076Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #20784

Change-Id: Ic07c78a86da5026e407ac9ecb3117d320c198048
Reviewed-on: https://go-review.googlesource.com/82016Reviewed-by: Andrew Bonventre <andybons@golang.org>

Just return the result of the function call as they are
both functionally equivalent.

Change-Id: Ia7847c9b018475051bf6f7a7c532b515bd68c024
Reviewed-on: https://go-review.googlesource.com/90375
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This is the benchmark result base on darwin with amd64 architecture:

name     old time/op  new time/op  delta
Cos      10.2ns ± 2%  10.3ns ± 3%  +1.18%  (p=0.032 n=10+10)
Cosh     25.3ns ± 3%  24.6ns ± 2%  -3.00%  (p=0.000 n=10+10)
Hypot    6.40ns ± 2%  6.19ns ± 3%  -3.36%  (p=0.000 n=10+10)
HypotGo  7.16ns ± 3%  6.54ns ± 2%  -8.66%  (p=0.000 n=10+10)
J0       66.0ns ± 2%  63.7ns ± 1%  -3.42%  (p=0.000 n=9+10)

Fixes #21812

Change-Id: I2b88fbdfc250cd548f8f08b44ce2eb172dcacf43
Reviewed-on: https://go-review.googlesource.com/84437Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Minor bug: `hubajazz.net` and `gitbapache.org` would match, probably shouldn't

GitHub-Last-Rev: 75bd338569ca41f83b9c36fe3d5ae3b4db0a26cc
GitHub-Pull-Request: golang/go#23755
Change-Id: Ie9c9ab1c15364eccdab8cf3b106b9c370e7f532f
Reviewed-on: https://go-review.googlesource.com/92997
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #23732

Disambiguate "too few" or "too many" values in struct
initializer messages by reporting the name of the literal.

After:
issue23732.go:27:3: too few values in Foo literal
issue23732.go:34:12: too many values in Bar literal
issue23732.go:40:6: too few values in Foo literal
issue23732.go:40:12: too many values in Bar literal

Change-Id: Ieca37298441d907ac78ffe960c5ab55741a362ef
Reviewed-on: https://go-review.googlesource.com/93277
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Previously find_goroutine determined whether a goroutine is
stopped by checking the sched.sp field. This heuristic doesn't
always hold but causes find_goroutine to return bogus pc/sp
info for running goroutines.

This change uses the atomicstatus bit to determine
the state which is more accurate.

R=go1.11

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

Instead evaluate and read the runtime internal constants
defined in runtime2.go

R=go1.11

Change-Id: If2f4b87e5b3f62f0c0ff1e86a90db8e37a78abb6
Reviewed-on: https://go-review.googlesource.com/87877
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>

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

and reorganize test log messages for stack dumps
for easier debugging.

The error log will be formatted like the following:

	trace_stack_test.go:282: Did not match event GoCreate with stack
		 runtime/trace_test.TestTraceSymbolize	 :39
		 testing.tRunner			 :0

		Seen 30 events of the type
		Offset 1890
		 runtime/trace_test.TestTraceSymbolize	/go/src/runtime/trace/trace_stack_test.go:30
		 testing.tRunner			/go/src/testing/testing.go:777
		Offset 1899
		 runtime/trace_test.TestTraceSymbolize	/go/src/runtime/trace/trace_stack_test.go:30
		 testing.tRunner			/go/src/testing/testing.go:777
		 ...

Change-Id: I0468de04507d6ae38ba84d99d13f7bf592e8d115
Reviewed-on: https://go-review.googlesource.com/92916Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>

name                old time/op    new time/op    delta
FindAllNoMatches-8     216ns ± 3%     122ns ± 2%   -43.52%  (p=0.000 n=10+10)

name                old alloc/op   new alloc/op   delta
FindAllNoMatches-8      240B ± 0%        0B       -100.00%  (p=0.000 n=10+10)

name                old allocs/op  new allocs/op  delta
FindAllNoMatches-8      1.00 ± 0%      0.00       -100.00%  (p=0.000 n=10+10)

This work was supported by Sourcegraph.

Change-Id: I30aac201370ccfb40a6ff637402020ac20f61f70
Reviewed-on: https://go-review.googlesource.com/87418
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #23776

Change-Id: Iff03d8b295afc1fd9435694b10246c723d323eda
Reviewed-on: https://go-review.googlesource.com/93296Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Kunpei Sakai <namusyaka@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Return an error if an Auth is passed to SendMail but the server does not support authentication.

Fixes #22145

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

Change Reader to promote TypeRegA to TypeReg in headers, unless their
name have a trailing slash which is already promoted to TypeDir. This
will allow client code to handle just TypeReg instead both TypeReg and
TypeRegA.

Change Writer to promote TypeRegA to TypeReg or TypeDir in the headers
depending on whether the name has a trailing slash. This normalization
is motivated by the specification (in pax(1)):

   0 represents a regular file. For backwards-compatibility, a
   typeflag value of binary zero ( '\0' ) should be recognized as
   meaning a regular file when extracting files from the
   archive. Archives written with this version of the archive file
   format create regular files with a typeflag value of the
   ISO/IEC 646:1991 standard IRV '0'.

Fixes #22768.

Change-Id: I149ec55824580d446cdde5a0d7a0457ad7b03466
Reviewed-on: https://go-review.googlesource.com/85656Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

iana.org, www.iana.org and data.iana.org all present a valid TLS
certificate, so let's use it when fetching data or linking to
resources to avoid errors in transit.

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

Fixes #23685

Change-Id: I3625bd01f860077ee0976df9e3dfb66754804bcd
Reviewed-on: https://go-review.googlesource.com/92535Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #23748

Change-Id: Iacdbd57c53492175cf1d3045640db61151e10731
Reviewed-on: https://go-review.googlesource.com/92955Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

I don't expect these to hit often, but we should still alert users if
we fail to write the correct data to the file, or fail to close it.

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

Now that the buffered write barrier is implemented for all
architectures, we can remove the old eager write barrier
implementation. This CL removes the implementation from the runtime,
support in the compiler for calling it, and updates some compiler
tests that relied on the old eager barrier support. It also makes sure
that all of the useful comments from the old write barrier
implementation still have a place to live.

Fixes #22460.

Updates #21640 since this fixes the layering concerns of the write
barrier (but not the other things in that issue).

Change-Id: I580f93c152e89607e0a72fe43370237ba97bae74
Reviewed-on: https://go-review.googlesource.com/92705
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Calls to writebarrierptr can simply be actual pointer writes. Calls to
writebarrierptr_prewrite need to go through the write barrier buffer.

Updates #22460.

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