- 19 Feb, 2014 13 commits
-
-
Russ Cox authored
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
-
Rick Arnold authored
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
-
Adam Langley authored
Fixes #6267. LGTM=r, josharian R=golang-codereviews, josharian, r CC=golang-codereviews https://golang.org/cl/61020043
-
Adam Langley authored
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
-
Russ Cox authored
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
-
Russ Cox authored
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
-
Rémy Oudompheng authored
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
-
Rémy Oudompheng authored
Fixes #6500. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/14920053
-
Rob Pike authored
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
-
Russ Cox authored
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
-
Dominik Honnef authored
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
-
Dominik Honnef authored
LGTM=adonovan R=adonovan CC=golang-codereviews https://golang.org/cl/62600043
-
Rick Arnold authored
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
-
- 18 Feb, 2014 10 commits
-
-
Brad Fitzpatrick authored
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
-
Brad Fitzpatrick authored
Unbreaks the build. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/65650043
-
Rob Pike authored
LGTM=mpvl R=mpvl CC=golang-codereviews https://golang.org/cl/65550044
-
Marcel van Lohuizen authored
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
-
Alex Brainman authored
LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/64980043
-
Andrew Gerrand authored
LGTM=r R=r CC=golang-codereviews https://golang.org/cl/64910043
-
Russ Cox authored
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
-
Nigel Tao authored
LGTM=dsymonds R=dsymonds CC=golang-codereviews https://golang.org/cl/64100045
-
Russ Cox authored
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
-
Russ Cox authored
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
-
- 17 Feb, 2014 5 commits
-
-
Dave Cheney authored
Callers of md5.Sum should do so to avoid allocations, the example did not demonstate this property. ««« original CL description crypto/md5: add example for Sum LGTM=dave R=golang-codereviews, dave CC=golang-codereviews https://golang.org/cl/64820044 »»» LGTM=minux.ma R=r, minux.ma CC=golang-codereviews https://golang.org/cl/65180043
-
ChaiShushan authored
LGTM=dave R=golang-codereviews, dave CC=golang-codereviews https://golang.org/cl/64820044
-
Ian Lance Taylor authored
LGTM=r R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/64090043
-
Dmitriy Vyukov authored
Add b.RunParallel function that captures parallel benchmark boilerplate: creates worker goroutines, joins worker goroutines, distributes work among them in an efficient way, auto-tunes grain size. Fixes #7090. R=bradfitz, iant, josharian, tracey.brendan, r, rsc, gobot CC=golang-codereviews https://golang.org/cl/57270043
-
Dmitriy Vyukov authored
Is it required? Why don't we do it? R=bradfitz CC=golang-codereviews https://golang.org/cl/61150043
-
- 16 Feb, 2014 5 commits
-
-
Dave Cheney authored
Update #7331 cgo is currently broken on freebsd/arm. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/63900043
-
Russ Cox authored
CL 64170043 disabled it in run.bash for Unix systems. I did not realize Windows systems also ran the race detector test. TBR=iant CC=golang-codereviews https://golang.org/cl/64480043
-
Russ Cox authored
Not recording the address being taken was causing the liveness analysis not to preserve x in the absence of direct references to x, which in turn was making the net test fail with GOGC=0. In addition to the test, this fixes a bug wherein GOGC=0 go test -short net crashed if liveness analysis was in use (like at tip, not like Go 1.2). TBR=ken2 CC=golang-codereviews https://golang.org/cl/64470043
-
Russ Cox authored
This problem was discovered by reading the code. I have not seen it in practice, nor do I have any ideas on how to trigger it reliably in a test. But it's still worth fixing. TBR=ken2 CC=golang-codereviews https://golang.org/cl/64370046
-
Russ Cox authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/64380043
-
- 15 Feb, 2014 3 commits
-
-
Russ Cox authored
The VARDEF placement must be before the initialization but after any final use. If you have something like s = ... using s ... the rhs must be evaluated, then the VARDEF, then the lhs assigned. There is a large comment in pgen.c on gvardef explaining this in more detail. This CL also includes Ian's suggestions from earlier CLs, namely commenting the use of mode in link.h and fixing the precedence of the ~r check in dcl.c. This CL enables the check that if liveness analysis decides a variable is live on entry to the function, that variable must be a function parameter (not a result, and not a local variable). If this check fails, it indicates a bug in the liveness analysis or in the generated code being analyzed. The race detector generates invalid code for append(x, y...). The code declares a temporary t and then uses cap(t) before initializing t. The new liveness check catches this bug and stops the compiler from writing out the buggy code. Consequently, this CL disables the race detector tests in run.bash until the race detector bug can be fixed (golang.org/issue/7334). Except for the race detector bug, the liveness analysis check does not detect any problems (this CL and the previous CLs fixed all the detected problems). The net test still fails with GOGC=0 but the rest of the tests now pass or time out (because GOGC=0 is so slow). TBR=iant CC=golang-codereviews https://golang.org/cl/64170043
-
Rémy Oudompheng authored
The existing tests issue4463.go and issue4654.go had failures at typechecking and did not test walking the AST. Fixes #7272. LGTM=khr R=khr, rsc, iant CC=golang-codereviews https://golang.org/cl/60550044
-
Rob Pike authored
Catch the error instead and return it to the user. Before this fix, the template package panicked. Now you get: template: bug11:1:14: executing "bug11" at <.PS>: dereference of nil pointer of type *string Extended example at http://play.golang.org/p/uP6pCW3qKT Fixes #7333. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/64150043
-
- 14 Feb, 2014 4 commits
-
-
Anthony Martin authored
The branchtags method was removed but we should've been using branchmap all along. http://selenic.com/hg/rev/4274eda143cb LGTM=franciscossouza, r R=golang-codereviews, franciscossouza, r CC=golang-codereviews https://golang.org/cl/57500045
-
Adam Langley authored
These should never be found in a bzip2 file but it does appear that there's a buggy encoder that is producing them. Since the official bzip2 handles this case, this change makes the Go code do likewise. With this change, the code produces the same output as the official bzip2 code on the invalid example given in the bug. Fixes #7279. LGTM=r R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/64010043
-
David du Colombier authored
Rfork is not splitting the stack when creating a new thread, so the parent and child are executing on the same stack. However, if the parent returns and keeps executing before the child can read the arguments from the parent stack, the child will not see the right arguments. The solution is to load the needed pieces from the parent stack into register before INT $64. Thanks to Russ Cox for the explanation. LGTM=rsc R=rsc CC=ality, golang-codereviews https://golang.org/cl/64140043
-
Michael T. Jones authored
Fixes #7329 LGTM=gri R=gri, bradfitz, mtj CC=golang-codereviews https://golang.org/cl/63710043
-