I just created that redirect, so we can change
it once the wiki moves.

LGTM=bradfitz, khr
R=khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/177780043

LGTM=dsymonds
R=dsymonds
CC=golang-codereviews, nmvc
https://golang.org/cl/169580043

LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/170660043

LGTM=bradfitz
R=bradfitz, alex.brainman
CC=golang-codereviews
https://golang.org/cl/168600044

Per private thread soliciting help. I realized part of this is
documented in several places, but we lacked a unifying
example.

LGTM=rsc
R=golang-codereviews
CC=adg, golang-codereviews, iant, rsc
https://golang.org/cl/171620043

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/143470043

LGTM=minux
R=adg, minux
CC=golang-codereviews
https://golang.org/cl/170520043

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/171560043

Language clarification.

The existing rules for selector expressions imply
automatic dereferencing of pointers to struct fields.
They also implied automatic dereferencing of selectors
denoting methods. In almost all cases, such automatic
dereferencing does indeed take place for methods but the
reason is not the selector rules but the fact that method
sets include both methods with T and *T receivers; so for
a *T actual receiver, a method expecting a formal T
receiver, also accepts a *T (and the invocation or method
value expression is the reason for the auto-derefering).

However, the rules as stated so far implied that even in
case of a variable p of named pointer type P, a selector
expression p.f would always be shorthand for (*p).f. This
is true for field selectors f, but cannot be true for
method selectors since a named pointer type always has an
empty method set.

Named pointer types may never appear as anonymous field
types (and method receivers, for that matter), so this
only applies to variables declared of a named pointer
type. This is exceedingly rare and perhaps shouldn't be
permitted in the first place (but we cannot change that).

Amended the selector rules to make auto-deref of values
of named pointer types an exception to the general rules
and added corresponding examples with explanations.

Both gc and gccgo have a bug where they do auto-deref
pointers of named types in method selectors where they
should not:

See http://play.golang.org/p/c6VhjcIVdM , line 45.

Fixes #5769.
Fixes #8989.

LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/168790043

LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/172980043

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/173920043

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/171360043

Fixes #9078.

LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/172920043

This patch is based only on reading the code.  I have not
tried to construct a test case.

Fixes #9077.

LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/172110043

Disable linkx_run.go and sinit_run.go, because they
exec subprocesses, which NaCl cannot.

TBR=r
CC=golang-codereviews
https://golang.org/cl/171350043

Follow-up in response to comments on
TBR'ed CL 171260043.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/172080043

Manifested as increased memory usage in a Google production system.

Not an unbounded leak, but can significantly increase the number
of sudogs allocated between garbage collections.

I checked all the other calls to acquireSudog.
This is the only one that was missing a releaseSudog.

LGTM=r, dneil
R=dneil, r
CC=golang-codereviews
https://golang.org/cl/169260043

These are being built into the runtime/cgo for every
operating system. It doesn't seem to matter, but
restore the Go 1.3 behavior anyway.

LGTM=r
R=r, dave
CC=golang-codereviews
https://golang.org/cl/171290043

LGTM=dave, bradfitz, r, alex.brainman
R=r, dave, bradfitz, alex.brainman
CC=golang-codereviews
https://golang.org/cl/167350043

LGTM=bradfitz, r
R=r, bradfitz
CC=golang-codereviews
https://golang.org/cl/168320043

This was a mistake. The cmd/api tool
depends on an old version of go/types.

««« original CL description
cmd/api: use golang.org/x/... import paths

LGTM=bradfitz, rsc
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/169000043
»»»

TBR=rsc, bradfitz
R=bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/169320043

This was a mistake; the cmd/api tool
depends on an old version of go/types.

««« original CL description
cmd/api: bump go.tools golden CL hash

TBR=bradfitz
R=rsc
CC=golang-codereviews
https://golang.org/cl/166380043
»»»

TBR=bradfitz, rsc
R=bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/167430043

TBR=bradfitz
R=rsc
CC=golang-codereviews
https://golang.org/cl/166380043

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/168170043

LGTM=rsc, r
R=r, rsc
CC=golang-codereview, golang-codereviews
https://golang.org/cl/168050043

LGTM=bradfitz, rsc
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/169000043

I've Mercurial version 3.2 and hg submit fails with:

  File "/home/agl/devel/go/lib/codereview/codereview.py", line 3567, in get_hg_status
    ret = hg_commands.status(fui, self.repo, *[], **{'rev': [rev], 'copies': True})
  File "/usr/lib/python2.7/site-packages/mercurial/commands.py", line 5714, in status
    fm = ui.formatter('status', opts)
  File "/home/agl/devel/go/lib/codereview/codereview.py", line 3464, in formatter
    return plainformatter(self, topic, opts)
  File "/usr/lib/python2.7/site-packages/mercurial/formatter.py", line 57, in __init__
    if ui.debugflag:
  AttributeError: 'FakeMercurialUI' object has no attribute 'debugflag'

This change dumbly adds a boolean debugflag and that seems to work.

LGTM=minux
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/167410043

New detection because of net/http now using TestMain.

Fixes #9033

LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, rsc
https://golang.org/cl/170210043

Fixes #9065.

LGTM=rsc
R=rsc, misch
CC=golang-codereviews
https://golang.org/cl/171270043

This was missing from CL 167320043.
Happy to apply comments in a followup.
TBR to fix build.

TBR=r
CC=golang-codereviews
https://golang.org/cl/171260043

Moving so that new Go 1.4 pprof can use it.

The old 'GNU objdump workalike' mode for 'go tool objdump'
is now gone, as are the tests for that mode. It was used only
by pre-Go 1.4 pprof. You can still specify an address range on
the command line; you just get the same output format as
you do when dumping the entire binary (without an address
limitation).

LGTM=r
R=r
CC=golang-codereviews, iant
https://golang.org/cl/167320043

LGTM=r
R=khr, r
CC=golang-codereviews
https://golang.org/cl/165590043

People viewing this locally will not have a /s/ on their local godoc.
tip.golang.org doesn't have one either.

Also change all golang.org links to https, to avoid mixed content
warnings when viewing https://golang.org/.

Fixes #9028.

LGTM=bradfitz, r
R=r, bradfitz
CC=adg, golang-codereviews
https://golang.org/cl/168250043

The remaining run-only tests will be migrated to run.go in another CL.

This CL will break the build due to issues 8746 and 8806.

Update #4139
Update #8746
Update #8806

LGTM=rsc
R=rsc, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/144630044

Stack bitmaps need to be scanned past any BitsDead entries.

Object bitmaps will not have any BitsDead in them (bitmap extraction stops at
the first BitsDead entry in makeheapobjbv).  data/bss bitmaps also have no BitsDead entries.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/168270043

CL 170720043 missed this one when adding +PCQuantum.

LGTM=iant
R=r, iant
CC=golang-codereviews
https://golang.org/cl/168090043

Fixes #9046.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/162680043

For some reason lsof is now hanging on my workstation
without the -b (avoid blocking in the kernel) option.
Adding -b makes the test pass and shouldn't hurt.

I don't know how recent the -b option is.  If the builders
are ok with it, it's probably ok.

LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/166220043

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/166230044

Gentraceback may grow the stack.
One of the gentraceback wrappers may grow the stack.
One of the gentraceback callback calls may grow the stack.
Various stack pointers are stored in various stack locations
as type uintptr during the execution of these calls.
If the stack does grow, these stack pointers will not be
updated and will start trying to decode stack memory that
is no longer valid.

It may be possible to change the type of the stack pointer
variables to be unsafe.Pointer, but that's pretty subtle and
may still have problems, even if we catch every last one.
An easier, more obviously correct fix is to require that
gentraceback of the currently running goroutine must run
on the g0 stack, not on the goroutine's own stack.

Not doing this causes faults when you set
        StackFromSystem = 1
        StackFaultOnFree = 1

The new check in gentraceback will catch future lapses.

The more general problem is calling getcallersp but then
calling a function that might relocate the stack, which would
invalidate the result of getcallersp. Add note to stubs.go
declaration of getcallersp explaining the problem, and
check all existing calls to getcallersp. Most needed fixes.

This affects Callers, Stack, and nearly all the runtime
profiling routines. It does not affect stack copying directly
nor garbage collection.

LGTM=khr
R=khr, bradfitz
CC=golang-codereviews, r
https://golang.org/cl/167060043