Match used len(ar.files) == 0 to mean "match everything"
but it also deleted matched things from the list, so once you
had matched everything you asked for, match returned true
for whatever was left in the archive too.

Concretely, if you have an archive containing f1, f2, then
        pack t foo.a f1
would match f1 and then, because len(ar.files) == 0 after
deleting f1 from the match list, also match f2.

Avoid the problem by recording explicitly whether match
matches everything.

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

The message used to say that there was a type
mismatch, which is not necessarily true.

TBR=ken2
CC=golang-codereviews
https://golang.org/cl/66600044

Fixes #7363.

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

The liblink refactor changed the DWARF .debug_line flow control. The mapping was off by one pcline entry. The fix here preserves pc until it can be compared to pcline.pc.

Sample dwarfdump .debug_line output for main.main from the program in issue 7351, before liblink (correct):

0x0000003c: 00 Extended: <9> 02 DW_LNE_set_address( 0x0000000000002000 )
0x00000047: 03 DW_LNS_advance_line( 6 )
0x00000049: 01 DW_LNS_copy
            0x0000000000002000      1      7      0 is_stmt

0x0000004a: 8b address += 21,  line += 1
            0x0000000000002021      1      8      0 is_stmt

0x0000004b: 02 DW_LNS_advance_pc( 153 )
0x0000004e: 03 DW_LNS_advance_line( 1 )
0x00000050: 01 DW_LNS_copy
            0x00000000000020ba      1      9      0 is_stmt

After liblink (off by one entry):

0x00001bbf: 00 Extended: <9> 02 DW_LNE_set_address( 0x0000000000002000 )
0x00001bca: 02 DW_LNS_advance_pc( 33 )
0x00001bcc: 03 DW_LNS_advance_line( 6 )
0x00001bce: 01 DW_LNS_copy
            0x0000000000002021      1      7      0 is_stmt

0x00001bcf: 02 DW_LNS_advance_pc( 153 )
0x00001bd2: 03 DW_LNS_advance_line( 1 )
0x00001bd4: 01 DW_LNS_copy
            0x00000000000020ba      1      8      0 is_stmt

0x00001bd5: 02 DW_LNS_advance_pc( 153 )
0x00001bd8: 03 DW_LNS_advance_line( 1 )
0x00001bda: 01 DW_LNS_copy
            0x0000000000002153      1      9      0 is_stmt

After this CL (the line 9 pc offset changed due to intervening compiler changes):

0x00001d07: 00 Extended: <9> 02 DW_LNE_set_address( 0x0000000000002000 )
0x00001d12: 03 DW_LNS_advance_line( 6 )
0x00001d14: 01 DW_LNS_copy
            0x0000000000002000      1      7      0 is_stmt

0x00001d15: 8b address += 21,  line += 1
            0x0000000000002021      1      8      0 is_stmt

0x00001d16: 02 DW_LNS_advance_pc( 189 )
0x00001d19: 03 DW_LNS_advance_line( 1 )
0x00001d1b: 01 DW_LNS_copy
            0x00000000000020de      1      9      0 is_stmt

Fixes #7351.

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

Rename should fail when the directory doesn't match.
It will fix the newly introduced test from cmd/pack
on Plan 9.

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

LGTM=minux.ma
R=golang-codereviews, minux.ma
CC=golang-codereviews
https://golang.org/cl/66470043

Try to prevent messages like this:
        './pack' file does not exist����������������������������������������������������������������������������������������������������
TBR=adonovan

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/66270043

otherwise go build command adds .exe suffix

Fixes #7362

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

Plan 9 uses single quotes, not double quotes. I should have known.

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

Windows at least doesn't emit one.
Maybe fix Windows build.

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

Get more information to help understand build failure on Plan 9.
Also Windows.
(TestHello is failing because GOCHAR does not appear in output.
What does?)

Update #7362

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

[Repeat of CL 64100044, after 32-bit fix in CL 66170043.]

Precisestack makes stack collection completely precise,
in the sense that there are no "used and not set" errors
in the collection of stack frames, no times where the collector
reads a pointer from a stack word that has not actually been
initialized with a pointer (possibly a nil pointer) in that function.

The most important part is interfaces: precisestack means
that if reading an interface value, the interface value is guaranteed
to be initialized, meaning that the type word can be relied
upon to be either nil or a valid interface type word describing
the data word.

This requires additional zeroing of certain values on the stack
on entry, which right now costs about 5% overall execution
time in all.bash. That cost will come down before Go 1.3
(issue 7345).

There are at least two known garbage collector bugs right now,
issues 7343 and 7344. The first happens even without precisestack.
The second I have only seen with precisestack, but that does not
mean that precisestack is what causes it. In fact it is very difficult
to explain by what precisestack does directly. Precisestack may
be exacerbating an existing problem. Both of those issues are
marked for Go 1.3 as well.

The reasons for enabling precisestack now are to give it more
time to soak and because the copying stack work depends on it.

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

The code here is being restored after its deletion in CL 14430048.

I restored the copy in cmd/6g in CL 56430043 but neglected the
other two.

This is the reason that enabling precisestack only worked on amd64.

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

When Go 1.3 is released, this will keep existing
Go 1.2 build scripts that use 'go tool pack grc' working.
For efficiency, such scripts should be changed to
use 6g -pack instead, but keeping the old behavior
available enables a more graceful transition.

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

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

There are probably more of these, but bound and len are 64 bits so use %lld
in message about array index out of bounds.
Fixes the 386 build.

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

Taking my own advice from a review of addr2line.

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

We never updated libmach for the new object file format,
so it the existing 'go tool addr2line' is broken.
Reimplement in Go to fix.

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

The error message was previously off by one in all cases.

Fixes #7150.

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

Fixes #6267.

LGTM=r, josharian
R=golang-codereviews, josharian, r
CC=golang-codereviews
https://golang.org/cl/61020043

Users of the low-level, Client function are frequenctly missing the
fact that, unless they pass a ServerName to the TLS connection then it
cannot verify the certificates against any name.

This change makes it clear that at least one of InsecureSkipVerify and
ServerName should always be set.

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

Update #6853

For an ephemeral binary - one created, run, and then deleted -
there is no need to write dwarf debug information, since the
binary will not be used with gdb. In this case, instruct the linker
not to spend time and disk space generating the debug information
by passing the -w flag to the linker.

Omitting dwarf information reduces the size of most binaries by 25%.
We may be more aggressive about this in the future.

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

Update #6853

Every function now has a gcargs and gclocals symbol
holding associated garbage collection information.
Put them all in the same meta-symbol as the go.func data
and then drop individual entries from symbol table.

Removing gcargs and gclocals reduces the size of a
typical binary by 10%.

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

Also re-enable race tests in run.bash.

Fixes #7334.

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

Fixes #6500.

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

IsNil isn't quite the same as == nil, as this snippet shows:

// http://play.golang.org/p/huomslDZgw
package main

import "fmt"
import "reflect"

func main() {
        var i interface{}
        v := reflect.ValueOf(i)
        fmt.Println(v.IsValid(), i == nil)
        fmt.Println(v.IsNil())
}

The fact that IsNil panics if you call it with an untyped nil
was not apparent. Verbiage added for clarity.

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

Update #6853

Nothing reads the Plan 9 symbol table anymore.
The last holdout was 'go tool nm', but since being rewritten in Go
it uses the standard symbol table for the binary format
(ELF, Mach-O, PE) instead.

Removing the Plan 9 symbol table saves ~15% disk space
on most binaries.

Two supporting changes included in this CL:

debug/gosym: use Go 1.2 pclntab to synthesize func-only
symbol table when there is no Plan 9 symbol table

debug/elf, debug/macho, debug/pe: ignore final EOF from ReadAt

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

c-mode classically uses ff-find-other-file to toggle between headers
and implementation. For Go it seemingly makes sense to jump between
implementation and test.

While there's no enforced mapping of file names for tests, the mapping
in this CL seems to be very common at least throughout the standard
library, and ff-find-other-file fails gracefully when the mapping
doesn't apply.

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/65750044

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/62600043

The code was returning the original value rather than the cloned value
resulting in the tests not being repeatable.

Fixes #7111.

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

Prevent bitrot. (similar to the previous sha1 and md5 CLs)

Fixes #6642

LGTM=agl
R=agl, dave
CC=golang-codereviews
https://golang.org/cl/65690043

Unbreaks the build.

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

LGTM=mpvl
R=mpvl
CC=golang-codereviews
https://golang.org/cl/65550044

This is a relatively minor change.

This does not result in changes to go.text/unicode/norm. The go.text
packages will therefore be relatively unaffected. It does make the
way for an upgrade to CLDR 24, though.

The tests of all.bash pass, as well as the tests in go.text after
this update.

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

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

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

broke 32-bit builds

««« original CL description
cmd/gc, runtime: enable precisestack by default

Precisestack makes stack collection completely precise,
in the sense that there are no "used and not set" errors
in the collection of stack frames, no times where the collector
reads a pointer from a stack word that has not actually been
initialized with a pointer (possibly a nil pointer) in that function.

The most important part is interfaces: precisestack means
that if reading an interface value, the interface value is guaranteed
to be initialized, meaning that the type word can be relied
upon to be either nil or a valid interface type word describing
the data word.

This requires additional zeroing of certain values on the stack
on entry, which right now costs about 5% overall execution
time in all.bash. That cost will come down before Go 1.3
(issue 7345).

There are at least two known garbage collector bugs right now,
issues 7343 and 7344. The first happens even without precisestack.
The second I have only seen with precisestack, but that does not
mean that precisestack is what causes it. In fact it is very difficult
to explain by what precisestack does directly. Precisestack may
be exacerbating an existing problem. Both of those issues are
marked for Go 1.3 as well.

The reasons for enabling precisestack now are to give it more
time to soak and because the copying stack work depends on it.

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

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

LGTM=dsymonds
R=dsymonds
CC=golang-codereviews
https://golang.org/cl/64100045

Precisestack makes stack collection completely precise,
in the sense that there are no "used and not set" errors
in the collection of stack frames, no times where the collector
reads a pointer from a stack word that has not actually been
initialized with a pointer (possibly a nil pointer) in that function.

The most important part is interfaces: precisestack means
that if reading an interface value, the interface value is guaranteed
to be initialized, meaning that the type word can be relied
upon to be either nil or a valid interface type word describing
the data word.

This requires additional zeroing of certain values on the stack
on entry, which right now costs about 5% overall execution
time in all.bash. That cost will come down before Go 1.3
(issue 7345).

There are at least two known garbage collector bugs right now,
issues 7343 and 7344. The first happens even without precisestack.
The second I have only seen with precisestack, but that does not
mean that precisestack is what causes it. In fact it is very difficult
to explain by what precisestack does directly. Precisestack may
be exacerbating an existing problem. Both of those issues are
marked for Go 1.3 as well.

The reasons for enabling precisestack now are to give it more
time to soak and because the copying stack work depends on it.

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

I have seen this cause leaks where not all objects in a sync.Pool
would be reclaimed during the sync package tests.
I found it while debugging the '0 of 100 finalized' failure we are
seeing on arm, but it seems not to be the root cause for that one.

LGTM=dave, dvyukov
R=golang-codereviews, dave, dvyukov
CC=golang-codereviews
https://golang.org/cl/64920044