The 'nodarg' function is used to obtain a Node*
representing a function argument or result.
It returned a brand new Node*, but that violates
the guarantee in most places in the compiler that
two Node*s refer to the same variable if and only if
they are the same Node* pointer. Reestablish that
invariant by making nodarg return a preexisting
named variable if present.

Having fixed that, avoid any copy during x=x in
componentgen, because the VARDEF we emit
before the copy marks the lhs x as dead incorrectly.

The change in walk.c avoids modifying the result
of nodarg. This was the only place in the compiler
that did so.

Fixes #8097.

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

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

Update #8112

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

Update #8112

Hide one-pass regexp API.

This means moving the code from regexp/syntax to regexp,
but it avoids being locked into the specific API chosen for
the implementation.

It also removes a slice field from the syntax.Inst, which
should avoid bloating the memory footprint of a non-one-pass
regexp unnecessarily.

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

For incomplete struct S, C.T and C.struct_S were interchangeable in Go 1.2
and earlier, because all incomplete types were interchangeable
(even C.struct_S1 and C.struct_S2).

CL 76450043, which fixed issue 7409, made different incomplete types
different from Go's point of view, so that they were no longer completely
interchangeable.

However, imprecision about C.T and C.struct_S - really the same
underlying C type - is the one behavior enabled by the bug that
is most likely to be depended on by existing cgo code.
Explicitly allow it, to keep that code working.

Fixes #7786.

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

Also made it extra clear for goto statements (even though label scopes
are already limited to the function defining a label).

Fixes #8040.

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

Map iteration order issue. Go 1.2 and earlier had stable results
for small maps.

Fixes #8115

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

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

This matters for NaCl, which seems to swamp my 4-core MacBook Pro otherwise.
It's not a correctness problem, just a usability problem.

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

This was sitting in my client but I forgot hg add.

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

Currently runtime derefences nil with m->locks>0,
which causes unrecoverable fatal error.
Panic instead.
Fixes #8045.

LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews, khr
https://golang.org/cl/97620043

CL 51010045 fixed the first one of these:

        cmd/gc: return canonical Node* from temp

        For historical reasons, temp was returning a copy
        of the created Node*, not the original Node*.
        This meant that if analysis recorded information in the
        returned node (for example, n->addrtaken = 1), the
        analysis would not show up on the original Node*, the
        one kept in fn->dcl and consulted during liveness
        bitmap creation.

        Correct this, and watch for it when setting addrtaken.

        Fixes #7083.

        R=khr, dave, minux.ma
        CC=golang-codereviews
        https://golang.org/cl/51010045

CL 53200043 fixed the second:

        cmd/gc: fix race build

        Missed this case in CL 51010045.

        TBR=khr
        CC=golang-codereviews
        https://golang.org/cl/53200043

This CL fixes the third. There are only three nod(OXXX, ...)
calls in sinit.c, so maybe we're done. Embarassing that it
took three CLs to find all three.

Fixes #8028.

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

In the first very rough draft of the reordering code
that was introduced in the Go 1.3 cycle, the pre-allocated
temporary for a ... argument was held in n->right.
It moved to n->alloc but the code avoiding n->right
was left behind in order.c. In copy(x, <-c), the receive
is in n->right and must be processed. Delete the special
case code, removing the bug.

Fixes #8039.

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

Fixes #8076.

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

The code was assuming that pointer alignment is the
maximum alignment, but on NaCl uint64 alignment is
even more strict.

Brad checked in the test earlier today; this fixes the build.

Fixes #7863.

TBR=iant
CC=golang-codereviews
https://golang.org/cl/98630046

Fixes #7638

LGTM=rsc
R=rsc, adg, robert.hencke, bradfitz
CC=golang-codereviews
https://golang.org/cl/89280043

The code cannot have worked before, because it was
trying to use the old value in a range check for the new
type, which might have a different representation
(hence the 'internal compiler error').

Fixes #8073.

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

fixes #8047

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

Fixes #7863

LGTM=rsc
R=rsc, ruiu
CC=golang-codereviews
https://golang.org/cl/98610045

Common mistake (at least for me) because hg etc. require the prefix
while the go command forbids it.

Before:
% go get http://code.google.com/p/go.text/unicode/norm
package http:/code.google.com/p/go.text/unicode/norm: unrecognized import path "http:/code.google.com/p/go.text/unicode/norm"

After:
% go get http://code.google.com/p/go.text/unicode/norm
package http:/code.google.com/p/go.text/unicode/norm: "http://" not allowed in import path

LGTM=ruiu, rsc
R=rsc, ruiu
CC=golang-codereviews
https://golang.org/cl/97630046

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

Update #8083

See discussion in https://groups.google.com/forum/#!topic/golang-dev/dh6Ra_xJomc

LGTM=khr
R=golang-codereviews, gobot, khr
CC=golang-codereviews
https://golang.org/cl/99440048

when deleting from a nil map.  See issue 8051.

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

Fixes #6720.

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

The spec was unclear about whether blank methods should be
permitted in interface types. gccgo permits at most one, gc
crashes if there are more than one, go/types permits at most
one.

Discussion:

Since method sets of non-interface types never contain methods
with blank names (blank methods are never declared), it is impossible
to satisfy an interface with a blank method.

It is possible to declare variables of assignable interface types
(but not necessarily identical types) containing blank methods, and
assign those variables to each other, but the values of those
variables can only be nil.

There appear to be two "reasonable" alternatives:

1) Permit at most one blank method (since method names must be unique),
and consider it part of the interface. This is what appears to happen
now, with corner-case bugs. Such interfaces can never be implemented.

2) Permit arbitrary many blank methods but ignore them. This appears
to be closer to the handling of blank identifiers in declarations.
However, an interface type literal is not a declaration (it's a type
literal). Also, for struct types, blank identifiers are not ignored;
so the analogy with declarations is flawed.

Both these alternatives don't seem to add any benefit and are likely
(if only slightly) more complicated to explain and implement than
disallowing blank methods in interfaces altogether.

Fixes #6604.

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

The key property here is what the bit pattern represents,
not what its type is. Storing 5 into a pointer is the problem.
Storing a uintptr that holds pointer bits back into a pointer
is not as much of a problem, and not what we are claiming
the runtime will detect.

Longer discussion at
https://groups.google.com/d/msg/golang-nuts/dIGISmr9hw0/0jO4ce85Eh0J

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

This is a quick documentation change/clarification, as this
confused me before: in my own cgo-based projects, I currently have
identical #cgo directives in each relevant source file, and I notice
with go build -x that cgo is combining the directives, leading to
pkg-config invocations with the same package name (gtk+-3.0, in my
case) repeated several times, or on Mac OS X, LDFLAGS listing
-framework Foundation -framework AppKit multiple times. Since I am
about to add a CFLAGS as well, I checked the source to cmd/cgo and
go/build (where the work is actually done) to see if that still holds
true there. Hopefully other people who have made the same mistake I
have (I don't know if anyone has) can remove the excess declarations
now; this should make things slightly easier to manage as well.

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

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/97660043

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

Update #8030

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

Ignore symbols that aren't text, data, or bss since they cause
problems when dissassembling instructions with small immediate
values.

Before:
        build.go:142    0x10ee  83ec50      SUBL $text/template/parse.autotmp_1293(SB), SP

After:
        build.go:142    0x10ee  83ec50      SUBL $0x50, SP

Fixes #7947.

LGTM=rsc
R=rsc, 0intro
CC=golang-codereviews
https://golang.org/cl/93520045

Noted by gri in CL 100660044 review but I missed them.

TBR=gri
CC=golang-codereviews
https://golang.org/cl/97570049

Add larger comment explaining testing methodology,
and derive tests arithmetically.

(These tests are checking rounding again; the derived
tests they replace were checking exact values.)

LGTM=r, gri
R=gri, r
CC=golang-codereviews
https://golang.org/cl/100660044

Passes the expanded test in CL 100660044,
which gives me some confidence that it
might be right.

(The old code failed by not considering all the
low bits.)

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

Rewrite formatFloat to be much simpler and clearer and
avoid the tricky interaction with padding.
The issue refers to complex but the problem is just floating-point.
The new tests added were incorrectly formatted before this fix.
Fixes #8064.

LGTM=jscrockett01, rsc
R=rsc, jscrockett01
CC=golang-codereviews
https://golang.org/cl/99420048

Fixes #8062.

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

Fixes #7983.

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews, rsc
https://golang.org/cl/96540044

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

These constants pass go/types constant conversions as well.

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

Fixes #8061.

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/93520046