This appears to be an unintended omission. The check func is declared
just above, and the err value from template.Parse is captured rather
than discarded via blank identifier. All following calls that similarly
return err are checked, so it can't be that this example elides error
checking for brevity. Finally, if you look at Example_autoescaping,
it does check err from template.Parse and its code is very similar.

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

Found by cmd/vet

Change-Id: I29dd207ecd40fe703054e8ad4e81b3267ca89da2
Reviewed-on: https://go-review.googlesource.com/17160Reviewed-by: David Crawshaw <crawshaw@golang.org>

- fix/check location of popdcl calls where questioned
- remove unnecessary handling of ... (LDDD) in ntype (couldn't be reached)
- inlined and fnret_type and simplified fnres as a consequence
- leave handling of ... (LDDD) in arg_list alone (remove TODO)
- verify that parser requires a ';' after last statement in a case/default
  (added test case)

Fixes #13243.

Change-Id: Iad94b498591a5e85f4cb15bbc01e8e101415560d
Reviewed-on: https://go-review.googlesource.com/17155
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Chris Manghane <cmang@golang.org>

Change-Id: I7c084542996226f3ed464314a5622fcfaac02d61
Reviewed-on: https://go-review.googlesource.com/17103Reviewed-by: Chris Manghane <cmang@golang.org>

No code changes.

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

The gccgo bug report https://gcc.gnu.org/PR65785 points out that the
multicast listen tests will use the network even with -test.short.
Fix test by checking testing.Short with a nil interface.

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

Previously it said, "bad verb %% for ...", which is not only wrong,
it's ironic as the fix is to use %% rather than % at the end of the
string. Diagnose the case where a simple % is at EOF.

If there's anything after the percent, the error is already good
but this CL also puts quotes around the verb designation ('%d' etc.)
to make it even clearer, especially when there is a space involved.

Fixes #12315.

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

For #13243.

Change-Id: I214945278255a49f93120f9407f536a6c01a29fb
Reviewed-on: https://go-review.googlesource.com/17101Reviewed-by: Chris Manghane <cmang@golang.org>

Use a combination of follow- and stop-token lists and nesting levels
to better synchronize parser after a syntax error.

Fixes #13319.

Change-Id: I9592e0b5b3ba782fb9f9315fea16163328e204f7
Reviewed-on: https://go-review.googlesource.com/17080Reviewed-by: Chris Manghane <cmang@golang.org>

Change-Id: I22a8a233bc157fa09cd0283fcd4bc14d90faed70
Reviewed-on: https://go-review.googlesource.com/17066Reviewed-by: Chris Manghane <cmang@golang.org>

Minor internal optimization.

Change-Id: I229d4a9df3da542b77f830c2830f63ec23ec1d61
Reviewed-on: https://go-review.googlesource.com/17065Reviewed-by: Chris Manghane <cmang@golang.org>

This never happens but for pathological input where a BOM sequence
is unfinished and ends in EOF (src: "package p\n\nfunc \xef\xef").
No test case added because the /test framework doesn't lend itself
easily to it in this case (file must end in EOF rather than comment).
Instead, tested manually.

Fixes #13268.

Change-Id: I049034e6dde7ad884b0a8c329921adac1866ff18
Reviewed-on: https://go-review.googlesource.com/17047Reviewed-by: Chris Manghane <cmang@golang.org>

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

This test depends on GODEBUG=gcstackbarrierall, which doesn't work on
ppc64.

Updates #13334.

Change-Id: Ie554117b783c4e999387f97dd660484488499d85
Reviewed-on: https://go-review.googlesource.com/17120
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

During a crash showing goroutine stacks of all threads
(with GOTRACEBACK=crash), it can be that f == nil.

Only happens on Solaris; not sure why.

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

(TestStackBarrierProfiling is failing on darwin/arm.)

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

Some Android OS installations have very strange permissions on their
/system/etc directory, meaning that Readdir fails. Instead use
/system/framework, which is far more regular.

Change-Id: Iefc140614183cda0f875e0f6ef859f4d4eaad9da
Reviewed-on: https://go-review.googlesource.com/17078Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Update golang/go#9327.

Change-Id: Iab7dad31cf6b9f9347c3f34faebb67ecb38b17fc
Reviewed-on: https://go-review.googlesource.com/16701
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

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

The nosplit stack is now much bigger, so we can afford to allocate
libcall on stack.

Fix asmsysvicall6 to not update errno if g == nil.

These two fixes TestCgoCallbackGC on solaris, which used to stuck
in a loop.

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

iEEETable violates the Go naming conventions and is inconsistent
with the rest of the package. Use ieeeTable instead.

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

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

All the heavy lifting was done by Michael Hudson-Doyle.

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

Solaris needs to make system calls without a g,
and Solaris uses asmcgocall to make system calls.
I know, I know.

I hope this makes CL 16915, fixing #12277, work on Solaris.

Change-Id: If988dfd37f418b302da9c7096f598e5113ecea87
Reviewed-on: https://go-review.googlesource.com/17072Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Run-TryBot: Russ Cox <rsc@golang.org>

Just add one word to clarify that -n -v -x are not the only build flags supported.

Fixes #13237.

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

Update #12416.

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

In the past, cgo generated Go code and C code.  The C code was linked
into a shared library.  The Go code was built into an executable that
dynamically linked against that shared library.  C wrappers were
exported from the shared library, and the Go code called them.

It was all a long time ago, but in order to permit C code to call back
into Go, somebody implemented #pragma dynexport (https://golang.org/cl/661043)
to export a Go symbol into the dynamic symbol table.  Then that same
person added code to cgo to recognize //export comments
(https://golang.org/cl/853042).  The //export comments were implemented
by generating C code, to be compiled by GCC, that would refer to C code,
to be compiled by 6c, that would call the Go code.  The GCC code would
go into a shared library.  The code compiled by 6c would be in the Go
executable.  The GCC code needed to refer to the 6c code, so the 6c
function was marked with #pragma dynexport.  The important point here is
that #pragma dynexport was used to expose an internal detail of the
implementation of an exported function, because at the time it was
necessary.

Moving forward to today, cgo no longer generates a shared library and 6c
no longer exists.  It's still true that we have a function compiled by
GCC that refers to a wrapper function now written in Go.  In the normal
case today we are doing an external link, and we use a
//go:cgo_export_static function to make the Go wrapper function visible
to the C code under a known name.

The #pragma dynexport statement has become a //go:cgo_export_dynamic
comment on the Go code.  That comment only takes effect when doing
internal linking.  The comment tells the linker to put the symbol in the
dynamic symbol table.  That still makes sense for the now unusual case
of using internal linking with a shared library.

However, all the changes to this code have carefully preserved the
property that the //go:cgo_export_dynamic comment refers to an internal
detail of the implementation of an exported function.  That was
necessary a long time ago, but no longer makes sense.

This CL changes the code to put the actual C-callable function into the
dynamic symbol table.  I considered dropping the comment entirely, but
it turns out that there is even a test for this, so I preserved it.

Change-Id: I66a7958e366e5974363099bfaa6ba862ca327849
Reviewed-on: https://go-review.googlesource.com/17061
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Fixes #13320.

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

The lack of this annotation causes Value.SetMapIndex to allocate
when it doesn't need to.

Add comments about why it's safe to do so.

Add a test to make sure we stay allocation-free.

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

It's intended primarily as a torture test for OS X.
Apparently Windows can't take it.

Updates fix for #12327.

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

sysmon runs without a P. This means it can't interact with the garbage
collector, so write barriers not allowed in anything that sysmon does.

Fixes #10600.

Change-Id: I9de1283900dadee4f72e2ebfc8787123e382ae88
Reviewed-on: https://go-review.googlesource.com/17006
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

allocm is a very unusual function: it is specifically designed to
allocate in contexts where m.p is nil by temporarily taking over a P.
Since allocm is used in many contexts where it would make sense to use
nowritebarrierrec, this commit teaches the nowritebarrierrec analysis
to stop at allocm.

Updates #10600.

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

This replaces *memHdr with memHdrPtr.

Updates #10600.

Change-Id: I673aa2cd20f29abec8ab91ed7e783718c8479ce1
Reviewed-on: https://go-review.googlesource.com/17009
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>

This replaces *traceAllocBlock with traceAllocBlockPtr.

Updates #10600.

Change-Id: I94a20d90f04cca7c457b29062427748e315e4857
Reviewed-on: https://go-review.googlesource.com/17004
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

gentraceback is used in many contexts where write barriers are
disallowed. This currently works because the only write barrier is in
assigning frame.argmap in setArgInfo and in practice frame is always
on the stack, so this write barrier is a no-op.

However, we can easily eliminate this write barrier, which will let us
statically disallow write barriers (using go:nowritebarrierrec
annotations) in many more situations. As a bonus, this makes the code
a little more idiomatic.

Updates #10600.

Change-Id: I45ba5cece83697ff79f8537ee6e43eadf1c18c6d
Reviewed-on: https://go-review.googlesource.com/17003
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

This is a bit of a belt-and-suspenders fix.
On OS X, we now parse the Mach-O file to find the __text section,
which is arguably the more proper fix. But it's a bit worrisome to
depend on a name like __text not changing, so we also read more
of the initial file (now 32 kB, up from 8 kB) and scan that too.

Fixes #12327.

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

My version of bash doesn't know what 'declare -A' means.

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

There was no documentation produced by "go doc cmd/asm".
Follow the style set by cmd/compile.

Fixes #13148.

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

The assumption is that there are no nested function calls in complex expressions.
For the most part that assumption is true. It wasn't for these calls inserted during walk.
Fix that.

I looked through all the calls to mkcall in walk and these were the only cases
that emitted calls, that could be part of larger expressions (like not delete),
and that were not already handled.

Fixes #12225.

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

Because there are now multiple packages that compose the runtime
we need to distinguish between the case where a runtime package
is being compiled versus the case the "runtime" package is being
compiled. In golang.org/cl/14204 I mistakenly used
  localpkg.Name == "runtime"
to check against the "runtime" package, but doing this would treat
a package with the path "foo.org/bar/runtime" as the runtime package.
The correct check is
  myimportpath == "runtime"
.

Change-Id: If90e95cef768d91206f2df1c06e27be876722e4e
Reviewed-on: https://go-review.googlesource.com/17059
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>