The current escape code panics when an action involves chain nodes.
Such nodes can be seen in the following situation:

{{ . | AAA.B }} - AAA being a registered function

The above expression is actually valid, because AAA could return a
map containing a B key. The tests in text/template explicitly
demonstrate this case.

Fix allIdents to cover also chain nodes.

While I was investigating this issue, I realized that the tests
introduced in similar CL 9621 were incorrect. Parse errors were
caught as expected, but for the wrong reason. Fixed them as well.
No changes in text/template code itself.

Fixes #10801

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

In 1.6, go doc is more likely to be available.

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

When go doc is invoked with a single package name argument (e.g. go doc pkgname)
it needs to find the directory of the requested package sources in GOPATH.

GOPATH might contain directories with the same name as the requested package
that do no contain any *.go files. This change makes "go doc" ignore such
directories when looking for possible package directories.

This fixes #10882

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

t.init() should be called at the time of template creation
i.e, template.New() and t.New() instead of later in the process.

- Removed calls of t.init() from t.Parse(), t.Execute(), t.Funcs()
- Also got rid of t.common != nil checks as it should never be nil

Fixes #10879

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

This was a simple oversight: the algorithm to handle recursive types
needed to be applied to the ignore-item case as well.

Fixes #10415.

Change-Id: I39ef31cad680ab8334e141f60d2f8707896785d1
Reviewed-on: https://go-review.googlesource.com/8942Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

runtime.GC() is intentionally very weakly specified. However, it is so
weakly specified that it's difficult to know that it's being used
correctly for its one intended use case: to ensure garbage collection
has run in a test that is garbage-sensitive. In particular, it is
unclear whether it is synchronous or asynchronous. In the old STW
collector this was essentially self-evident; short of queuing up a
garbage collection to run later, it had to be synchronous. However,
with the concurrent collector, there's evidence that people are
inferring that it may be asynchronous (e.g., issue #10986), as this is
both unclear in the documentation and possible in the implementation.

In fact, runtime.GC() runs a fully synchronous STW collection. We
probably don't want to commit to this exact behavior. But we can
commit to the essential property that tests rely on: that runtime.GC()
does not return until the GC has finished.

Change-Id: Ifc3045a505e1898ecdbe32c1f7e80e2e9ffacb5b
Reviewed-on: https://go-review.googlesource.com/10488Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Change-Id: Ic00882735d95d61f7c9d9f28d34cb4acce6a5546
Reviewed-on: https://go-review.googlesource.com/10556Reviewed-by: Minux Ma <minux@golang.org>

As noted in bug #10980, an empty PEM block is encoded as
-----BEGIN foo-----
-----END foo-----

However, Decode failed to process this.

RFC 1421 doesn't answer what the encoding of the empty block should be
because PEM messages always contain at least one header. However, PEM
these days is just the encoding format – nobody uses the rest of PEM any
longer.

Having the empty block not contain a newline seems most correct because
https://tools.ietf.org/html/rfc1421#section-9 clearly says that the
optional “pemtext” carries the leading new-line with it. So if omitted,
the new-line should be omitted too.

None the less, this changes makes encoding/pem permissive, accepting any
number of blank lines in an empty PEM block.

Fixes #10980

Change-Id: If36bdfbf991ee281eccd50b56ddc95f24c6debb2
Reviewed-on: https://go-review.googlesource.com/10516Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>

I think it's worth mentioning.
But the final decision is up to you.

Change-Id: I3959132600ecc554988524ede73a7f6e8eac8353
Reviewed-on: https://go-review.googlesource.com/10551Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

They're each architecture-specific.
Let them share.

Reduces Prog size to 288, which is the
next smaller malloc class.

Reduces inuse_space while compiling the
rotate tests by ~3.2%.

Change-Id: Ica8ec90e466c97b569745fffff0e5acd364e55fa
Reviewed-on: https://go-review.googlesource.com/10514Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

That which cannot happen has not happened.

No immediate changes to Addr or Prog size.

Change-Id: I4cb9315f2c9f5f92eda340bfc4abb46395fa467f
Reviewed-on: https://go-review.googlesource.com/10513Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Printed and Width were unused.

Despite only removing two bytes, due to alignment, 8 bytes are saved
on 64-bit:

Before: unsafe.Sizeof(obj.Prog{}) == 304
 After: unsafe.Sizeof(obj.Prog{}) == 296

The next size class below 320 (304=>19(320)) is 288. Still 8 bytes
away from that.

Change-Id: I8d1632dd40d387f7036c03c65ea4d64e9b6218c3
Reviewed-on: https://go-review.googlesource.com/10511
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Change-Id: I55a7f455ebbd6b1bd6912aae82c0fcff6f43387c
Reviewed-on: https://go-review.googlesource.com/10512
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Missed in previous CL, causing build failures.

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

- (*Float).Scan conflicted with fmt.Scanner.Scan; it was also only used
  internally. Removed it, as well as the companion ScanFloat function.

- (*Float).Parse (and thus ParseFloat) can now also parse infinities.
  As a result, more code could be simplified.

- Fixed a bug in rounding (round may implicitly be called for infinite
  values). Found via existing test cases, after simplifying some code.

- Added more test cases.

Fixes issue #10938.

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

This paves the way for a fmt-compatible (*Float).Format method.
A better name then Text is still desirable (suggestions welcome).

This is partly fixing issue #10938.

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

It is almost never set and Addr is large, so having the full struct
in the Prog wastes memory most of the time.

Before (on a 64-bit system):

$ sizeof -p cmd/internal/obj Addr Prog
Addr 80
Prog 376
$

After:

$ sizeof -p cmd/internal/obj Addr Prog
Addr 80
Prog 304
$

Change-Id: I491f201241f87543964a7d0f48b85830759be9d0
Reviewed-on: https://go-review.googlesource.com/10457Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Change-Id: Iddcd0cfb8f2c2f1c4ad7a94b50a9f65b543862c4
Reviewed-on: https://go-review.googlesource.com/10473Reviewed-by: Minux Ma <minux@golang.org>

Fixes #10968.

Change-Id: I027bc571a71629ac49c2a0ff101b2950af6e7531
Reviewed-on: https://go-review.googlesource.com/10482Reviewed-by: David Symonds <dsymonds@golang.org>
Run-TryBot: David Symonds <dsymonds@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I7aeb9fef3739c17c03fdaadbe00cd945ec9c0d72
Reviewed-on: https://go-review.googlesource.com/10492
Run-TryBot: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #10979.

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

Memory usage has been reduced.
The tests are still slow,
but that is issue #10571.

/usr/bin/time shows significant variation
in the peak memory usage compiling with tip.
This is unsurprising, given GC.

Using Go 1.4.2, memory is stable at 410mb.
Using tip at d2ee09298,
memory ranges from 470mb (+15%) to 534mb (+30%),
with a mean of 504mb (+23%), with n=50.

Fixes #9933.

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

Use pkgimport == nil (or not) to distinguish between
parsing .go source files where "p" exponent specifier
is not allowed and parsing .a or .o export data where
it is.  Use that to control error when p-exponent is
seen.

Fixes #9036

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

This is an automated follow-up to CL 10210.
It was generated with a combination of eg and gofmt -r.

No functional changes. Passes toolstash -cmp.

Change-Id: I35f5897948a270b472d8cf80612071b4b29e9a2b
Reviewed-on: https://go-review.googlesource.com/10253Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

TestGoroutineParallelism can deadlock if the GC runs during the
test. Currently it tries to prevent this by forcing a GC before the
test, but this is best effort and fails completely if GOGC is very low
for testing.

This change replaces this best-effort fix with simply setting GOGC to
off for the duration of the test.

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

Currently when the race detector is enabled, orderexpr always creates
a temporary for slice and append operations. This used to be necessary
because the race detector had a different code path for slice
assignment that required this temporary. Unfortunately, creating this
temporary inhibits the optimization that eliminates write barriers
when a slice is assigned only to change its length or cap. For most
code, this is bad for performance, and in go:nowritebarrier functions
in the runtime, this can mean the difference between compiling and not
compiling.

Now the race detector uses the regular slice assignment code, so
creating this temporary is no longer necessary.

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

Most runtime tests that invoke the compiler to build a sub-test binary
do so with a special environment constructed by testEnv that strips
out environment variables that should apply to the test but not to the
build.

Fix TestGdbPython to use this test environment when invoking go build,
like other tests do.

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

A decimal represented 0.0 with a 0-length mantissa and undefined
exponent, but the formatting code assumes a valid zero exponent
if the float value is 0.0. The code worked because we allocate a
new decimal value each time and because there's no rounding that
lead to 0.0.

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

Change-Id: I3a6df0a76d57db7cb6910f4179a6ce380f219a37
Reviewed-on: https://go-review.googlesource.com/10442Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This is dead code that was missed
during the 'go tool compile' migration.

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

It shrinks Prog type from 448 bytes down to 376 bytes on amd64.

It also makes sense, because I don't know of any modern architecture
that have instructions which can write to two destinations, none of
which is a register (even x86 doesn't have such instructions).

Change-Id: I3061f1c9ac93d79ee2b92ecb9049641d0e0f6300
Reviewed-on: https://go-review.googlesource.com/10330Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

This speeds up sharded builds notably, by 1 second * the number of
tests.

Change-Id: Ib0295c31e4974f3003f72cb16c48949812b6f22b
Reviewed-on: https://go-review.googlesource.com/10460Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

- factor out handling of sign
- rename bstring, pstring to fmtB, fmtP consistent with fmtE, fmtF
- move all float-to-string conversion functions into ftoa.go
- no functional changes

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

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

Fixes #10956

Change-Id: If8517094f04250c4f722e1e899a237eb6e170eb9
Reviewed-on: https://go-review.googlesource.com/10421
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Added a lineno parameter to treecopy and listtreecopy
(ignored if = 0).  When nodes are copied the copy is
assigned the non-zero lineno (normally this would be
the destination).

Fixes #8183

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

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

We already read the address of a gcmask/gcprog out of the type data, but I
didn't know how many bytes to read. But it turns out that it's easy to
calculate, so change to do that. This means that we no longer depend on the
local symbols being present, allowing me to strip the shared libraries for
distribution and make them a lot smaller.

As a bonus, this makes LSym another 24 bytes smaller, down to 296 bytes now.

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

The motivation for this is the innocuous looking test case that is added. This
creates a stack exe -> libdep2.so -> libdep.so -> libruntime.so. The problem
comes from the fact that a function from libdep.so gets inlined all the way
into exe. This (unsurprisingly) means that the object file for exe references
symbols from libdep.so, which means that -ldep needs to be passed when linking
exe and it isn't. The fix is simply to pass it -- there is no harm in passing
it when it's not needed.

The thing is, it's not clear at all in the current code to see how the linker
can know that libdep2 is linked against libdep. It could look through the
DT_NEEDED entries in libdep2 and try to guess which are Go libraries, but it
feels better to be explicit. So this adds another SHT_NOTE section that lists
the shared libraries a shared library was linked against, and makes sure the
complete set of depended upon shared libraries is passed to the external
linker.

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