Exported methods of unexported embedded structs get added
correctly to the pool. Behavior is unchanged before and after
https://golang.org/cl/14085.
Change-Id: I2b4053bab02ff045f0a4577b8114808a60aae27e
Reviewed-on: https://go-review.googlesource.com/16305
Reviewed-by: Russ Cox <rsc@golang.org>
Steve Newman (Google CLA) was missing from the CONTRIBUTORS file,
presumably because his old commits (made prior to Go being open
source) in SVN/perforce were imported into hg/git later as
"devnull@localhost", which probably didn't match anything, and we
didn't start tracking CLA contributions prior to the Go
open source release.
As a fun historical note, the initial HTTP client from Steve:
https://github.com/golang/go/commit/f315fb3
Change-Id: I2b8da4564d99820504788ecc41495a62391078d5
Reviewed-on: https://go-review.googlesource.com/16864
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a translation of the yacc-based parser with adjustements
to make the grammar work for a recursive-descent parser followed
by cleanups and simplifications.
The yacc actions were mostly literally copied for correctness
with better temporary names.
A few of the syntax tests were adjusted for slightly different
error messages (it is very difficult to match the yacc-based
error messages in all cases, and sometimes the new parser could
produce better errors).
The new parser is enabled by default.
To switch back to the yacc-based parser, set -oldparser.
To hardwire the switch back, uncomment "oldparser = 1" in lex.go.
- passes all.bash
- ~18% reduced parse time per file on average for make.bash
- ~3% reduced compile time for building cmd/compile
Change-Id: Icb5651bb9d8b9f66261762d2c94a03793050d4ce
Reviewed-on: https://go-review.googlesource.com/16665
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Fix the output of build -n when adding to an existing archive with the
gc toolchain by observing that we are, now, always doing that. When
using the gc toolchain the archive is now always created by the Go
compiler, and never by the pack command.
No test because we have not historically tested build -n output.
Fixes#13118.
Change-Id: I3a5c43cf45169fa6c9581e4741309c77d2b6e58b
Reviewed-on: https://go-review.googlesource.com/16761
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The gzip package is asymmetrical in the way it handles headers.
In Writer, the Header is written on the first call to Write, Flush, or Close.
In Reader, the Header is read on calls to NewReader or Reset as opposed to
after the first Read. Thus, we document this difference.
Fixes#13211
Change-Id: I5f87beff036e5e2fd68a02a15fdb7137e9ca4c37
Reviewed-on: https://go-review.googlesource.com/16838
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Allows removing fields that aren't relevant to a particular OS or
changing their types to match the underlying OS system calls they'll
be used for.
Change-Id: I5cea89ee77b4e7b985bff41337e561887c3272ff
Reviewed-on: https://go-review.googlesource.com/16176
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
so that GO_TEST_TIMEOUT_SCALE can be applied too.
It's for the mips64 builder, which is so slow that the
go1 benchmark can't finish startup within 10 minutes.
Change-Id: I1b824eb0649460101b294fb442da784e872403e7
Reviewed-on: https://go-review.googlesource.com/16901
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Replaces PID in PaxHeaders with 0. Sorts PAX header keys before writing
them to the archive.
Fixes#12358
Change-Id: If239f89c85f1c9d9895a253fb06a47ad44960124
Reviewed-on: https://go-review.googlesource.com/13975
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Joe Tsai <joetsai@digital-static.net>
We're allocating TLS storage for m0 anyway, so might as well use it.
Change-Id: I7dc20bbea5320c8ab8a367f18a9540706751e771
Reviewed-on: https://go-review.googlesource.com/16890
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#13198
The output of netsh is encoded with ANSI encoding. So doesn't match with UTF-8 strings.
Write output as UTF-8 using powershell.
Change-Id: I6c7e93c590ed407f24ae847601d71df9523e028c
Reviewed-on: https://go-review.googlesource.com/16756
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This requires changing the tls access code to match the patterns documented in
the ABI documentation or the system linker will "optimize" it into ridiculousness.
With this change, -buildmode=pie works, although as it is tested in testshared,
the tests are not run yet.
Change-Id: I1efa6687af0a5b8db3385b10f6542a49056b2eb3
Reviewed-on: https://go-review.googlesource.com/15971
Reviewed-by: Russ Cox <rsc@golang.org>
The PowerPC ISA does not have a PC-relative load instruction, which poses
obvious challenges when generating position-independent code. The way the ELFv2
ABI addresses this is to specify that r2 points to a per "module" (shared
library or executable) TOC pointer. Maintaining this pointer requires
cooperation between codegen and the system linker:
* Non-leaf functions leave space on the stack at r1+24 to save the TOC pointer.
* A call to a function that *might* have to go via a PLT stub must be followed
by a nop instruction that the system linker can replace with "ld r1, 24(r1)"
to restore the TOC pointer (only when dynamically linking Go code).
* When calling a function via a function pointer, the address of the function
must be in r12, and the first couple of instructions (the "global entry
point") of the called function use this to derive the address of the TOC
for the module it is in.
* When calling a function that is implemented in the same module, the system
linker adjusts the call to skip over the instructions mentioned above (the
"local entry point"), assuming that r2 is already correctly set.
So this changeset adds the global entry point instructions, sets the metadata so
the system linker knows where the local entry point is, inserts code to save the
TOC pointer at 24(r1), adds a nop after any call not known to be local and copes
with the odd non-local code transfer in the runtime (e.g. the stuff around
jmpdefer). It does not actually compile PIC yet.
Change-Id: I7522e22bdfd2f891745a900c60254fe9e372c854
Reviewed-on: https://go-review.googlesource.com/15967
Reviewed-by: Russ Cox <rsc@golang.org>
darwin/386, freebsd/386, and linux/386 use a setldt system call to
setup each M's thread-local storage area, and they need access to the
M's id for this. The current code copies m.id into m.tls[0] (and this
logic has been cargo culted to OSes like NetBSD and OpenBSD, which
don't even need m.id to configure TLS), and then the 386 assembly
loads m.tls[0]... but since the assembly code already has a pointer to
the M, it might as well just load m.id directly.
Change-Id: I1a7278f1ec8ebda8d1de3aa3a61993070e3a8cdf
Reviewed-on: https://go-review.googlesource.com/16881
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The larger stack frames causes the nosplit stack to overflow so the next change
increases the stackguard.
Change-Id: Ib2b4f24f0649eb1d13e3a58d265f13d1b6cc9bf9
Reviewed-on: https://go-review.googlesource.com/15964
Reviewed-by: Russ Cox <rsc@golang.org>
Larger stack frames mean nosplit functions use more stack and so the limit
needs to increase.
The change to test/nosplit.go is a bit ugly but I can't really think of a
way to make it nicer.
Change-Id: I2616b58015f0b62abbd62951575fcd0d2d8643c2
Reviewed-on: https://go-review.googlesource.com/16504
Reviewed-by: Russ Cox <rsc@golang.org>
Apparently its last use was removed in CL 8899.
Change-Id: I4f3a789b3cc4c249582e81463af62b576a281e40
Reviewed-on: https://go-review.googlesource.com/16880
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The new revision is 389d49d4943780efbfcd2a434f4462b6d0f23c44 (Nov 13, 2015).
The runtimes are built using the new x/build/cmd/racebuild utility.
This update fixes a bug in race detection algorithm that can
lead to occasional false negatives (#10589). But generally just
brings in an up-to-date runtime.
Update #8653Fixes#10589
Change-Id: I7ac9614d014ee89c2302ce5e096d326ef293f367
Reviewed-on: https://go-review.googlesource.com/16827
Reviewed-by: Keith Randall <khr@golang.org>
As per mdempsky's comment on golang.org/cl/14204, textflag.h is
copied to the includes dir by cmd/dist, and the copy in
runtime/internal/atomic is not actually being used.
Updates #11647
Change-Id: Ie95c08903a9df54cea4c70ee9d5291176f7b5609
Reviewed-on: https://go-review.googlesource.com/16871
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Fixes#10802
Compare Volume name and each path elements using strings.EqualFold.
Change-Id: Ibdefdb801d0326e53755bc9cc8c10eed998094e5
Reviewed-on: https://go-review.googlesource.com/16795
Reviewed-by: Russ Cox <rsc@golang.org>
Somehow these were left out of the orignial CL.
Updates #11647
Change-Id: I058a30eaa25fbb72d60e7fb6bc9ff0a3b54fdb2a
Reviewed-on: https://go-review.googlesource.com/16870
Reviewed-by: Minux Ma <minux@golang.org>
Calling flag.Parse twice can be problematic if other goroutines called
flag.Parsed in between: the race detector complains due to the
write after read from a different goroutine.
This can happen if TestMain calls flag.Parse and launches goroutines
that call flag.Parsed, for example if it initializes a server which
checks flags.
This patch makes testing.M.Run only parse the flags if they have not
been parsed already.
Change-Id: Id9f8c31c5f90614e3f34c63d1a32cf7e9055d68e
Reviewed-on: https://go-review.googlesource.com/16739
Reviewed-by: Russ Cox <rsc@golang.org>
The heap profile is only guaranteed to be up-to-date after two GC
cycles, so force two GCs instead of just one.
Updates #13098.
Change-Id: I4fb9287b698f4a3b90b8af9fc6a2efb3b082bfe5
Reviewed-on: https://go-review.googlesource.com/16848
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
I made a copy of the per-arch _CacheLineSize definitons when checking in
runtime/internal/atomic. Now that runtime/internal/sys is checked in,
we can use the definition there.
Change-Id: I7242f6b633e4164f033b67ff471416b9d71c64d2
Reviewed-on: https://go-review.googlesource.com/16847
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
sigprof tracebacks the stack across systemstack switches to make
profile tracebacks more complete. However, it does this even if the
user stack is currently being copied, which means it may be in an
inconsistent state that will cause the traceback to panic.
One specific way this can happen is during stack shrinking. Some
goroutine blocks for STW, then enters gchelper, which then assists
with root marking. If that root marking happens to pick the original
goroutine and its stack needs to be shrunk, it will begin to copy that
stack. During this copy, the stack is generally inconsistent and, in
particular, the actual locations of the stack barriers and their
recorded locations are temporarily out of sync. If a SIGPROF happens
during this inconsistency, it will walk the stack all the way back to
the blocked goroutine and panic when it fails to unwind the stack
barriers.
Fix this by disallowing jumping to the user stack during SIGPROF if
that user stack is in the process of being copied.
Fixes#12932.
Change-Id: I9ef694c2c01e3653e292ce22612418dd3daff1b4
Reviewed-on: https://go-review.googlesource.com/16819
Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reverts commit bc1f9d20b4.
The current go-get strategy doesn't support cases that servers
cannot handle shallow clients.
Also, `go get -u` is broken and is not compatible with already
go-getted unshallow repos.
Fixes#13213.
Fixes#13206.
Change-Id: Ie89d7603d96d323db64ad82997793fda0972f709
Reviewed-on: https://go-review.googlesource.com/16832
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The file was automatically placed in the cl by a tool I had built.
Since the compiler doesn't hook into the atomic package, it's unnecessary.
Change-Id: I631fd876813b381bb12604865b00fc5b268dce84
Reviewed-on: https://go-review.googlesource.com/16844
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I keep losing this utility, used as part of other tools to auto-update
the AUTHORS and CONTRIBUTORS files. Check it in to the repo so I
don't lose it, and so others can use it as well.
Updates #12042
Change-Id: Ib5886b85799087aaaddcec4c81169e2726322c05
Reviewed-on: https://go-review.googlesource.com/16824
Reviewed-by: Russ Cox <rsc@golang.org>
runtime/internal/sys will hold system-, architecture- and config-
specific constants.
Updates #11647
Change-Id: I6db29c312556087a42e8d2bdd9af40d157c56b54
Reviewed-on: https://go-review.googlesource.com/16817
Reviewed-by: Russ Cox <rsc@golang.org>
The heapsampling.go test occasionally fails on some architectures
because it finds zero heap samples in main.alloc. This happens because
the byte and object counts are only updated at a GC. Hence, if a GC
happens part way through allocInterleaved, but then doesn't happen
after we start calling main.alloc, checkAllocations will see buckets
for the lines in main.alloc (which are created eagerly), but the
object and byte counts will be zero.
Fix this by forcing a GC to update the profile before we collect it.
Fixes#13098.
Change-Id: Ia7a9918eea6399307f10499dd7abefd4f6d13cf6
Reviewed-on: https://go-review.googlesource.com/16846
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Correct an error in the last change: it caused runtime/cgo and
runtime/race to not depend on runtime.
Fixes#13214.
Change-Id: Ib48b3b5e9a74567ddfaccb7ab4a897ee2aedc2b8
Reviewed-on: https://go-review.googlesource.com/16837
Reviewed-by: Michael Matloob <matloob@golang.org>
