CC=golang-codereviews
https://golang.org/cl/124050043

Generated by a+c.

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

When formatting time zone offsets with seconds using the stdISO8601Colon
and stdNumColon layouts, the colon was missing between the hour and minute
parts.

Fixes #8497.

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

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

There was a number of improvements related to GC parallelization:
1. Parallel roots/stacks scanning.
2. Parallel stack shrinking.
3. Per-thread workbuf caches.
4. Workset reduction.
Currently 32 threads work well.
go.benchmarks:garbage benchmark on 2 x Intel Xeon E5-2690 (16 HT cores)

1 thread/1 processor:
time=16405255
cputime=16386223
gc-pause-one=546793975
gc-pause-total=3280763

2 threads/1 processor:
time=9043497
cputime=18075822
gc-pause-one=331116489
gc-pause-total=2152257

4 threads/1 processor:
time=4882030
cputime=19421337
gc-pause-one=174543105
gc-pause-total=1134530

8 threads/1 processor:
time=4134757
cputime=20097075
gc-pause-one=158680588
gc-pause-total=1015555

16 threads/1 processor + HT:
time=2006706
cputime=31960509
gc-pause-one=75425744
gc-pause-total=460097

16 threads/2 processors:
time=1513373
cputime=23805571
gc-pause-one=56630946
gc-pause-total=345448

32 threads/2 processors + HT:
time=1199312
cputime=37592764
gc-pause-one=48945064
gc-pause-total=278986

LGTM=rlh
R=golang-codereviews, tracey.brendan, rlh
CC=golang-codereviews, khr, rsc
https://golang.org/cl/123920043

Update #8092

LGTM=dvyukov
R=golang-codereviews, minux, dvyukov
CC=golang-codereviews
https://golang.org/cl/122250043

Stack shrinking happens during mark phase,
and it assumes that it owns stackcache in mcache.
Stack cache flushing also happens during mark phase,
and it accesses stackcache's w/o any synchronization.
This leads to stackcache corruption:
http://goperfd.appspot.com/log/309af5571dfd7e1817259b9c9cf9bcf9b2c27610

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

On OS X 10.10 Yosemite, if you have a directory that can be returned
in a single getdirentries64 call (for example, a directory with one file),
and you read from the directory at EOF twice, you get EOF both times:
        fd = open("dir")
        getdirentries64(fd) returns data
        getdirentries64(fd) returns 0 (EOF)
        getdirentries64(fd) returns 0 (EOF)

But if you remove the file in the middle between the two calls, the
second call returns an error instead.
        fd = open("dir")
        getdirentries64(fd) returns data
        getdirentries64(fd) returns 0 (EOF)
        remove("dir/file")
        getdirentries64(fd) returns ENOENT/EINVAL

Whether you get ENOENT or EINVAL depends on exactly what was
in the directory. It is deterministic, just data-dependent.

This only happens in small directories. A directory containing more data
than fits in a 4k getdirentries64 call will return EOF correctly.
(It's not clear if the criteria is that the directory be split across multiple
getdirentries64 calls or that it be split across multiple file system blocks.)

We could change package os to avoid the second read at EOF,
and maybe we should, but that's a bit involved.
For now, treat the EINVAL/ENOENT as EOF.

With this CL, all.bash passes on my MacBook Air running
OS X 10.10 (14A299l) and Xcode 6 beta 5 (6A279r).

I tried filing an issue with Apple using "Feedback Assistant", but it was
unable to send the report and lost it.

C program reproducing the issue, also at http://swtch.com/~rsc/readdirbug.c:

#include <stdio.h>
#include <dirent.h>
#include <unistd.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>

static void test(int);

int
main(void)
{
        int fd, n;
        DIR *dir;
        struct dirent *dp;
        struct stat st;
        char buf[10000];
        long basep;
        int saw;

        if(stat("/tmp/readdirbug", &st) >= 0) {
                fprintf(stderr, "please rm -r /tmp/readdirbug and run again\n");
                exit(1);
        }

        fprintf(stderr, "mkdir /tmp/readdirbug\n");
        if(mkdir("/tmp/readdirbug", 0777) < 0) {
                perror("mkdir /tmp/readdirbug");
                exit(1);
        }

        fprintf(stderr, "create /tmp/readdirbug/file1\n");
        if((fd = creat("/tmp/readdirbug/file1", 0666)) < 0) {
                perror("create /tmp/readdirbug/file1");
                exit(1);
        }
        close(fd);

        test(0);
        test(1);

        fprintf(stderr, "ok - everything worked\n");
}

static void
test(int doremove)
{
        DIR *dir;
        struct dirent *dp;
        int numeof;

        fprintf(stderr, "\n");
        fprintf(stderr, "opendir /tmp/readdirbug\n");
        dir = opendir("/tmp/readdirbug");
        if(dir == 0) {
                perror("open /tmp/readdirbug");
                exit(1);
        }

        numeof = 0;
        for(;;) {
                errno = 0;
                dp = readdir(dir);
                if(dp != 0) {
                        fprintf(stderr, "readdir: found %s\n", dp->d_name);
                        continue;
                }
                if(errno != 0) {
                        perror("readdir");
                        exit(1);
                }
                fprintf(stderr, "readdir: EOF\n");
                if(++numeof == 3)
                        break;
                if(doremove) {
                        fprintf(stderr, "rm /tmp/readdirbug/file1\n");
                        if(remove("/tmp/readdirbug/file1") < 0) {
                                perror("remove");
                                exit(1);
                        }
                }
        }
        fprintf(stderr, "closedir\n");
        closedir(dir);
}

Fixes #8423.

LGTM=bradfitz, r
R=golang-codereviews, bradfitz, dsymonds, dave, r
CC=golang-codereviews, iant
https://golang.org/cl/119530044

All goroutines decode into the same value.

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

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

as per rsc request

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

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

Current version of Getwd calls Stat that
calls Getwd therefore infinite recursion.

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

Fixes #8342.

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

Fixes #8314.

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

Fixes #8181.

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

According to the OpenBSD builder, it doesn't work.

TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/126830043

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

CC=golang-codereviews
https://golang.org/cl/123950043

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

According to the FreeBSD builder, it doesn't work.

TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/121400043

C compiler does not support unnamed fields.

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

The ast and printer don't care, and go/types can provide
a better error message.

This change requires an update to the tests for go/types
(go.tools repo). CL forthcoming.

Fixes #8493.

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

Some systems, like Ubuntu, pass --build-id when linking.  The
effect is to put a note in the output file.  This is not
useful when generating an object file with the -r option, as
it eventually causes multiple build ID notes in the final
executable, all but one of which are for tiny portions of the
file and are therefore useless.

Disable that by passing an explicit --build-id=none when
linking with -r on systems that might do this.

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

LGTM=dvyukov
R=dvyukov, khr
CC=golang-codereviews
https://golang.org/cl/121030043

There are lots of internal synchronization in gob,
so it makes sense to have parallel benchmarks.
Also add a benchmark with slices and interfaces.

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

This lets us have non-main packages like cmd/internal or cmd/nm/internal/whatever.

The src/pkg migration (see golang.org/s/go14mainrepo) will allow this
as a natural side effect. The explicit change here just allows use of the
effect a little sooner.

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

To do in another CL: make cmd/objdump use cmd/internal/objfile too.

There is a package placement decision in this CL:
cmd/internal/objfile instead of internal/objfile.
I chose to put internal under cmd to make clear (and enforce)
that no standard library packages should use this
(it's a bit dependency-heavy).

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

Update #8314

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

Eliminating use of this extension makes it easier to port the Go runtime
to other compilers. This CL also disables the extension in cc to prevent
accidental use.

LGTM=rsc, khr
R=rsc, aram, khr, dvyukov
CC=axwalk, golang-codereviews
https://golang.org/cl/106790044

This makes os.Getwd mimic C getwd on OS X,
and possibly other systems. The change on OS X
was a regression from 1.2 to 1.3.

Fixes #8400.

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

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

benchmark                      old ns/op     new ns/op     delta
BenchmarkMalloc8               28.7          22.4          -21.95%
BenchmarkMalloc16              44.8          33.8          -24.55%
BenchmarkMallocTypeInfo8       49.0          32.9          -32.86%
BenchmarkMallocTypeInfo16      46.7          35.8          -23.34%
BenchmarkMallocLargeStruct     907           901           -0.66%
BenchmarkGobDecode             13235542      12036851      -9.06%
BenchmarkGobEncode             10639699      9539155       -10.34%
BenchmarkJSONEncode            25193036      21898922      -13.08%
BenchmarkJSONDecode            96104044      89464904      -6.91%

Fixes #8452.

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

Fix few remaining cases after cl/117580043.

TBR=dfc
R=golang-codereviews
CC=dave, golang-codereviews
https://golang.org/cl/124850043

FlagNoGC is unused now.
FlagNoInvokeGC is unneeded as we don't invoke GC
on g0 and when holding locks anyway.
mal/malloc have very few uses and you never remember
the exact set of flags they use and the difference between them.
Moreover, eventually we need to give exact types to all allocations,
something what mal/malloc do not support.

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

Shrinkstack does not touch normal heap anymore,
so we can shink stacks concurrently with marking.

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

Fixes #8403.

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

LGTM=dan.kortschak, dave
R=dave, dan.kortschak
CC=golang-codereviews
https://golang.org/cl/121350043

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

LGTM=minux
R=r, agl, minux
CC=golang-codereviews
https://golang.org/cl/121340043