An error occurred fetching the project authors.
- 10 Apr, 2015 1 commit
-
-
Dmitry Vyukov authored
The flag updates error annotations in test files from actual compiler output. This is useful when doing compiler changes that add/remove/change lots of errors, or when adding lots of new tests. Also I noticed at least 2 cases where annotation were sub-optimal: 1. The annotation was "leaking param p" when the actual error is "leaking param p to result ~r1". 2. The annotation was "leaking param m" when the actual errors are "leaking param m" and "leaking param mv1". For now it works only for errorcheck mode. Also, apply the update to escape and liveness tests. Some files have gccgo-specific errors of the form "gc error|gccgo error", so it is risky to run update on all files. Gccgo-specific error does not necessary contain '|', it can be just truncated. Change-Id: Iaaae767f859dcb8321a8cb4970b2b70969e8a345 Reviewed-on: https://go-review.googlesource.com/5310 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 09 Apr, 2015 1 commit
-
-
Dmitry Vyukov authored
Fixes #10353 See test/escape2.go:issue10353. Previously new(int) did not escape to heap, and so heap-allcated closure was referencing a stack var. This breaks the invariant that heap must not contain pointers to stack. Look at the following program: package main func main() { foo(new(int)) bar(new(int)) } func foo(x *int) func() { return func() { println(*x) } } // Models what foo effectively does. func bar(x *int) *C { return &C{x} } type C struct { x *int } Without this patch escape analysis works as follows: $ go build -gcflags="-m -m -m -l" esc.go escflood:1: dst ~r1 scope:foo[0] escwalk: level:0 depth:0 func literal( l(9) f(1) esc(no) ld(1)) scope:foo[1] /tmp/live2.go:9: func literal escapes to heap escwalk: level:0 depth:1 x( l(8) class(PPARAM) f(1) esc(no) ld(1)) scope:foo[1] /tmp/live2.go:8: leaking param: x to result ~r1 escflood:2: dst ~r1 scope:bar[0] escwalk: level:0 depth:0 &C literal( l(15) esc(no) ld(1)) scope:bar[1] /tmp/live2.go:15: &C literal escapes to heap escwalk: level:-1 depth:1 &C literal( l(15)) scope:bar[0] escwalk: level:-1 depth:2 x( l(14) class(PPARAM) f(1) esc(no) ld(1)) scope:bar[1] /tmp/live2.go:14: leaking param: x /tmp/live2.go:5: new(int) escapes to heap /tmp/live2.go:4: main new(int) does not escape new(int) does not escape while being captured by the closure. With this patch escape analysis of foo and bar works similarly: $ go build -gcflags="-m -m -m -l" esc.go escflood:1: dst ~r1 scope:foo[0] escwalk: level:0 depth:0 &(func literal)( l(9)) scope:foo[0] escwalk: level:-1 depth:1 func literal( l(9) f(1) esc(no) ld(1)) scope:foo[1] /tmp/live2.go:9: func literal escapes to heap escwalk: level:-1 depth:2 x( l(8) class(PPARAM) f(1) esc(no) ld(1)) scope:foo[1] /tmp/live2.go:8: leaking param: x escflood:2: dst ~r1 scope:bar[0] escwalk: level:0 depth:0 &C literal( l(15) esc(no) ld(1)) scope:bar[1] /tmp/live2.go:15: &C literal escapes to heap escwalk: level:-1 depth:1 &C literal( l(15)) scope:bar[0] escwalk: level:-1 depth:2 x( l(14) class(PPARAM) f(1) esc(no) ld(1)) scope:bar[1] /tmp/live2.go:14: leaking param: x /tmp/live2.go:4: new(int) escapes to heap /tmp/live2.go:5: new(int) escapes to heap Change-Id: Ifd14b7ae3fc11820e3b5eb31eb07f35a22ed0932 Reviewed-on: https://go-review.googlesource.com/8408Reviewed-by:
Russ Cox <rsc@golang.org> Run-TryBot: Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 30 Mar, 2015 1 commit
-
-
David Chase authored
Extend escape analysis to convT2E and conT2I. If the interface value does not escape supply runtime with a stack buffer for the object copy. This is a straight port from .c to .go of Dmitry's patch Change-Id: Ic315dd50d144d94dd3324227099c116be5ca70b6 Reviewed-on: https://go-review.googlesource.com/8201Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
- 28 Mar, 2015 2 commits
-
-
Dmitry Vyukov authored
The false positives (var incorrectly escapes) are marked with BAD. Change-Id: If64fabb6ea96de44a1177d9ab12e2ccc579fe0c4 Reviewed-on: https://go-review.googlesource.com/5294Reviewed-by:
Keith Randall <khr@golang.org>
-
Dmitry Vyukov authored
False positives (var incorrectly escapes) are marked with BAD. Change-Id: I646a29ffe24d963c63db09cba81dbc101d7c7242 Reviewed-on: https://go-review.googlesource.com/5296Reviewed-by:
Keith Randall <khr@golang.org>
-
- 25 Feb, 2015 1 commit
-
-
Chris Manghane authored
Fixes #9083. Change-Id: Ifbdebafb39a73a1dacf7e67171e8e88028d1f10b Reviewed-on: https://go-review.googlesource.com/1219Reviewed-by:
Russ Cox <rsc@golang.org> Run-TryBot: Chris Manghane <cmang@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 12 Feb, 2015 2 commits
-
-
Dmitry Vyukov authored
Extend escape analysis to make(map[k]v). If it does not escape, allocate temp buffer for hmap and one bucket on stack. There are 75 cases of non-escaping maps in std lib. benchmark old allocs new allocs delta BenchmarkConcurrentStmtQuery 16161 15161 -6.19% BenchmarkConcurrentTxQuery 17658 16658 -5.66% BenchmarkConcurrentTxStmtQuery 16157 15156 -6.20% BenchmarkConcurrentRandom 13637 13114 -3.84% BenchmarkManyConcurrentQueries 22 20 -9.09% BenchmarkDecodeComplex128Slice 250 188 -24.80% BenchmarkDecodeFloat64Slice 250 188 -24.80% BenchmarkDecodeInt32Slice 250 188 -24.80% BenchmarkDecodeStringSlice 2250 2188 -2.76% BenchmarkNewEmptyMap 1 0 -100.00% BenchmarkNewSmallMap 2 0 -100.00% benchmark old ns/op new ns/op delta BenchmarkNewEmptyMap 124 55.7 -55.08% BenchmarkNewSmallMap 317 148 -53.31% benchmark old allocs new allocs delta BenchmarkNewEmptyMap 1 0 -100.00% BenchmarkNewSmallMap 2 0 -100.00% benchmark old bytes new bytes delta BenchmarkNewEmptyMap 48 0 -100.00% BenchmarkNewSmallMap 192 0 -100.00% Fixes #5449 Change-Id: I24fa66f949d2f138885d9e66a0d160240dc9e8fa Reviewed-on: https://go-review.googlesource.com/3508Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
-
Dmitry Vyukov authored
Support the following conversions in escape analysis: []rune("foo") []byte("foo") string([]rune{}) If the result does not escape, allocate temp buffer on stack and pass it to runtime functions. Change-Id: I1d075907eab8b0109ad7ad1878104b02b3d5c690 Reviewed-on: https://go-review.googlesource.com/3590Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 29 Jan, 2015 1 commit
-
-
Dmitry Vyukov authored
Language specification says that variables are captured by reference. And that is what gc compiler does. However, in lots of cases it is possible to capture variables by value under the hood without affecting visible behavior of programs. For example, consider the following typical pattern: func (o *Obj) requestMany(urls []string) []Result { wg := new(sync.WaitGroup) wg.Add(len(urls)) res := make([]Result, len(urls)) for i := range urls { i := i go func() { res[i] = o.requestOne(urls[i]) wg.Done() }() } wg.Wait() return res } Currently o, wg, res, and i are captured by reference causing 3+len(urls) allocations (e.g. PPARAM o is promoted to PPARAMREF and moved to heap). But all of them can be captured by value without changing behavior. This change implements simple strategy for capturing by value: if a captured variable is not addrtaken and never assigned to, then it is captured by value (it is effectively const). This simple strategy turned out to be very effective: ~80% of all captures in std lib are turned into value captures. The remaining 20% are mostly in defers and non-escaping closures, that is, they do not cause allocations anyway. benchmark old allocs new allocs delta BenchmarkCompressedZipGarbage 153 126 -17.65% BenchmarkEncodeDigitsSpeed1e4 91 69 -24.18% BenchmarkEncodeDigitsSpeed1e5 178 129 -27.53% BenchmarkEncodeDigitsSpeed1e6 1510 1051 -30.40% BenchmarkEncodeDigitsDefault1e4 100 75 -25.00% BenchmarkEncodeDigitsDefault1e5 193 139 -27.98% BenchmarkEncodeDigitsDefault1e6 1420 985 -30.63% BenchmarkEncodeDigitsCompress1e4 100 75 -25.00% BenchmarkEncodeDigitsCompress1e5 193 139 -27.98% BenchmarkEncodeDigitsCompress1e6 1420 985 -30.63% BenchmarkEncodeTwainSpeed1e4 109 81 -25.69% BenchmarkEncodeTwainSpeed1e5 211 151 -28.44% BenchmarkEncodeTwainSpeed1e6 1588 1097 -30.92% BenchmarkEncodeTwainDefault1e4 103 77 -25.24% BenchmarkEncodeTwainDefault1e5 199 143 -28.14% BenchmarkEncodeTwainDefault1e6 1324 917 -30.74% BenchmarkEncodeTwainCompress1e4 103 77 -25.24% BenchmarkEncodeTwainCompress1e5 190 137 -27.89% BenchmarkEncodeTwainCompress1e6 1327 919 -30.75% BenchmarkConcurrentDBExec 16223 16220 -0.02% BenchmarkConcurrentStmtQuery 17687 16182 -8.51% BenchmarkConcurrentStmtExec 5191 5186 -0.10% BenchmarkConcurrentTxQuery 17665 17661 -0.02% BenchmarkConcurrentTxExec 15154 15150 -0.03% BenchmarkConcurrentTxStmtQuery 17661 16157 -8.52% BenchmarkConcurrentTxStmtExec 3677 3673 -0.11% BenchmarkConcurrentRandom 14000 13614 -2.76% BenchmarkManyConcurrentQueries 25 22 -12.00% BenchmarkDecodeComplex128Slice 318 252 -20.75% BenchmarkDecodeFloat64Slice 318 252 -20.75% BenchmarkDecodeInt32Slice 318 252 -20.75% BenchmarkDecodeStringSlice 2318 2252 -2.85% BenchmarkDecode 11 8 -27.27% BenchmarkEncodeGray 64 56 -12.50% BenchmarkEncodeNRGBOpaque 64 56 -12.50% BenchmarkEncodeNRGBA 67 58 -13.43% BenchmarkEncodePaletted 68 60 -11.76% BenchmarkEncodeRGBOpaque 64 56 -12.50% BenchmarkGoLookupIP 153 139 -9.15% BenchmarkGoLookupIPNoSuchHost 508 466 -8.27% BenchmarkGoLookupIPWithBrokenNameServer 245 226 -7.76% BenchmarkClientServer 62 59 -4.84% BenchmarkClientServerParallel4 62 59 -4.84% BenchmarkClientServerParallel64 62 59 -4.84% BenchmarkClientServerParallelTLS4 79 76 -3.80% BenchmarkClientServerParallelTLS64 112 109 -2.68% BenchmarkCreateGoroutinesCapture 10 6 -40.00% BenchmarkAfterFunc 1006 1005 -0.10% Fixes #6632. Change-Id: I0cd51e4d356331d7f3c5f447669080cd19b0d2ca Reviewed-on: https://go-review.googlesource.com/3166Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 28 Jan, 2015 4 commits
-
-
Dmitry Vyukov authored
If result of string(i) does not escape, allocate a [4]byte temp on stack for it. Change-Id: If31ce9447982929d5b3b963fd0830efae4247c37 Reviewed-on: https://go-review.googlesource.com/3411Reviewed-by:
Russ Cox <rsc@golang.org>
-
Dmitry Vyukov authored
Currently we always allocate string buffers in heap. For example, in the following code we allocate a temp string just for comparison: if string(byteSlice) == "abc" { ... } This change extends escape analysis to cover []byte->string conversions and string concatenation. If the result of operations does not escape, compiler allocates a small buffer on stack and passes it to slicebytetostring and concatstrings. Then runtime uses the buffer if the result fits into it. Size of the buffer is 32 bytes. There is no fundamental theory behind this number. Just an observation that on std lib tests/benchmarks frequency of string allocation is inversely proportional to string length; and there is significant number of allocations up to length 32. benchmark old allocs new allocs delta BenchmarkFprintfBytes 2 1 -50.00% BenchmarkDecodeComplex128Slice 318 316 -0.63% BenchmarkDecodeFloat64Slice 318 316 -0.63% BenchmarkDecodeInt32Slice 318 316 -0.63% BenchmarkDecodeStringSlice 2318 2316 -0.09% BenchmarkStripTags 11 5 -54.55% BenchmarkDecodeGray 111 102 -8.11% BenchmarkDecodeNRGBAGradient 200 188 -6.00% BenchmarkDecodeNRGBAOpaque 165 152 -7.88% BenchmarkDecodePaletted 319 309 -3.13% BenchmarkDecodeRGB 166 157 -5.42% BenchmarkDecodeInterlacing 279 268 -3.94% BenchmarkGoLookupIP 153 135 -11.76% BenchmarkGoLookupIPNoSuchHost 508 466 -8.27% BenchmarkGoLookupIPWithBrokenNameServer 245 226 -7.76% BenchmarkClientServerParallel4 62 61 -1.61% BenchmarkClientServerParallel64 62 61 -1.61% BenchmarkClientServerParallelTLS4 79 78 -1.27% BenchmarkClientServerParallelTLS64 112 111 -0.89% benchmark old ns/op new ns/op delta BenchmarkFprintfBytes 381 311 -18.37% BenchmarkStripTags 2615 2351 -10.10% BenchmarkDecodeNRGBAGradient 3715887 3635096 -2.17% BenchmarkDecodeNRGBAOpaque 3047645 2928644 -3.90% BenchmarkGoLookupIP 153 135 -11.76% BenchmarkGoLookupIPNoSuchHost 508 466 -8.27% Change-Id: I9ec01da816945c3329d7be3c7794b520418c3f99 Reviewed-on: https://go-review.googlesource.com/3120Reviewed-by:
Keith Randall <khr@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Dmitry Vyukov authored
Escape analysis treats everything assigned to OIND/ODOTPTR as escaping. As the result b escapes in the following code: func (b *Buffer) Foo() { n, m := ... b.buf = b.buf[n:m] } This change recognizes such assignments and ignores them. Update issue #9043. Update issue #7921. There are two similar cases in std lib that benefit from this optimization. First is in archive/zip: type readBuf []byte func (b *readBuf) uint32() uint32 { v := binary.LittleEndian.Uint32(*b) *b = (*b)[4:] return v } Second is in time: type data struct { p []byte error bool } func (d *data) read(n int) []byte { if len(d.p) < n { d.p = nil d.error = true return nil } p := d.p[0:n] d.p = d.p[n:] return p } benchmark old ns/op new ns/op delta BenchmarkCompressedZipGarbage 32431724 32217851 -0.66% benchmark old allocs new allocs delta BenchmarkCompressedZipGarbage 153 143 -6.54% Change-Id: Ia6cd32744e02e36d6d8c19f402f8451101711626 Reviewed-on: https://go-review.googlesource.com/3162Reviewed-by:
Keith Randall <khr@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Dmitry Vyukov authored
Currently all PTRLIT element initializers escape. There is no reason for that. This change links STRUCTLIT to PTRLIT; STRUCTLIT element initializers are already linked to the STRUCTLIT. As the result, PTRLIT element initializers escape when PTRLIT itself escapes. Change-Id: I89ecd8677cbf81addcfd469cd2fd461c0e9bf7dd Reviewed-on: https://go-review.googlesource.com/3031Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 24 Sep, 2014 1 commit
-
-
Russ Cox authored
Fixes #8585. Removes some little-used code paths. LGTM=josharian R=golang-codereviews, minux, josharian CC=golang-codereviews, iant, r https://golang.org/cl/132970043
-
- 11 Jun, 2014 2 commits
-
-
Russ Cox authored
There is a hierarchy of location defined by loop depth: -1 = the heap 0 = function results 1 = local variables (and parameters) 2 = local variable declared inside a loop 3 = local variable declared inside a loop inside a loop etc In general if an address from loopdepth n is assigned to something in loop depth m < n, that indicates an extended lifetime of some form that requires a heap allocation. Function results can be local variables too, though, and so they don't actually fit into the hierarchy very well. Treat the address of a function result as level 1 so that if it is written back into a result, the address is treated as escaping. Fixes #8185. LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/108870044
-
Russ Cox authored
The analysis for &x was using the loop depth on x set during x's declaration. A type switch creates a list of implicit declarations that were not getting initialized with loop depths. Fixes #8176. LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/108860043
-
- 03 Jun, 2014 1 commit
-
-
Russ Cox authored
I introduced this bug when I changed the escape analysis to run in phases based on call graph dependency order, in order to be more precise about inputs escaping back to outputs (functions returning their arguments). Given func f(z **int) *int { return *z } we were tagging the function as 'z does not escape and is not returned', which is all true, but not enough information. If used as: var x int p := &x q := &p leak(f(q)) then the compiler might try to keep x, p, and q all on the stack, since (according to the recorded information) nothing interesting ends up being passed to leak. In fact since f returns *q = p, &x is passed to leak and x needs to be heap allocated. To trigger the bug, you need a chain that the compiler wants to keep on the stack (like x, p, q above), and you need a function that returns an indirect of its argument, and you need to pass the head of the chain to that function. This doesn't come up very often: this bug has been present since June 2012 (between Go 1 and Go 1.1) and we haven't seen it until now. It helps that most functions that return indirects are getters that are simple enough to be inlined, avoiding the bug. Earlier versions of Go also had the benefit that if &x really wasn't used beyond x's lifetime, nothing broke if you put &x in a heap-allocated structure accidentally. With the new stack copying, though, heap-allocated structures containing &x are not updated when the stack is copied and x moves, leading to crashes in Go 1.3 that were not crashes in Go 1.2 or Go 1.1. The fix is in two parts. First, in the analysis of a function, recognize when a value obtained via indirect of a parameter ends up being returned. Mark those parameters as having content escape back to the return results (but we don't bother to write down which result). Second, when using the analysis to analyze, say, f(q), mark parameters with content escaping as having any indirections escape to the heap. (We don't bother trying to match the content to the return value.) The fix could be less precise (simpler). In the first part we might mark all content-escaping parameters as plain escaping, and then the second part could be dropped. Or we might assume that when calling f(q) all the things pointed at by q escape always (for any f and q). The fix could also be more precise (more complex). We might record the specific mapping from parameter to result along with the number of indirects from the parameter to the thing being returned as the result, and then at the call sites we could set up exactly the right graph for the called function. That would make notleaks(f(q)) be able to keep x on the stack, because the reuslt of f(q) isn't passed to anything that leaks it. The less precise the fix, the more stack allocations become heap allocations. This fix is exactly as precise as it needs to be so that none of the current stack allocations in the standard library turn into heap allocations. Fixes #8120. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, khr, r https://golang.org/cl/102040046
-
- 12 May, 2014 1 commit
-
-
Russ Cox authored
Fixes #7931. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/100390044
-
- 09 May, 2014 1 commit
-
-
Russ Cox authored
If the ... element type contained no pointers, then the escape analysis did not track the ... itself. This manifested in an escaping ...byte being treated as non-escaping. Fixes #7934. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/100310043
-
- 14 Feb, 2014 1 commit
-
-
Russ Cox authored
Make the loop nesting depth of &x depend on where x is declared, not on where the &x appears. The latter is only a conservative estimate of the former. Being more careful can avoid some variables escaping, and it is easier to reason about. It would have avoided issue 7313, although that was still a bug worth fixing. Not much effect in the tree: one variable in the whole tree is saved from a heap allocation (something in x509 parsing). LGTM=daniel.morsing R=daniel.morsing CC=golang-codereviews https://golang.org/cl/62380043
-
- 13 Feb, 2014 1 commit
-
-
Daniel Morsing authored
Logically, the init statement is in the enclosing scopes loopdepth, not inside the for loop. Fixes #7313. LGTM=rsc R=golang-codereviews, gobot, rsc CC=golang-codereviews https://golang.org/cl/62430043
-
- 17 Sep, 2013 1 commit
-
-
Robert Griesemer authored
See also issue 6414. R=r CC=golang-dev https://golang.org/cl/13683044
-
- 25 Jun, 2013 1 commit
-
-
Russ Cox authored
Functions without bodies were excluded from the ordering logic, because when I wrote the ordering logic there was no reason to analyze them. But then we added //go:noescape tags that need analysis, and we didn't update the ordering logic. So in the absence of good ordering, //go:noescape only worked if it appeared before the use in the source code. Fixes #5773. R=golang-dev, r CC=golang-dev https://golang.org/cl/10570043
-
- 22 May, 2013 1 commit
-
-
Rémy Oudompheng authored
R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/9676043
-
- 21 Mar, 2013 1 commit
-
-
Russ Cox authored
R=ken2 CC=golang-dev https://golang.org/cl/7518050
-
- 15 Mar, 2013 1 commit
-
-
Rémy Oudompheng authored
It used to not mark parameters as escaping if only one of the fields it points to leaks out of the function. This causes problems when importing from another package. Fixes #4964. R=rsc, lvd, dvyukov, daniel.morsing CC=golang-dev https://golang.org/cl/7648045
-
- 05 Feb, 2013 2 commits
-
-
Russ Cox authored
A new comment directive //go:noescape instructs the compiler that the following external (no body) func declaration should be treated as if none of its arguments escape to the heap. Fixes #4099. R=golang-dev, dave, minux.ma, daniel.morsing, remyoudompheng, adg, agl, iant CC=golang-dev https://golang.org/cl/7289048
-
Russ Cox authored
If the analysis reached a node twice, then the analysis was cut off. However, if the second arrival is at a lower depth (closer to escaping) then it is important to repeat the traversal. The repeating must be cut off at some point to avoid the occasional infinite recursion. This CL cuts it off as soon as possible while still passing all tests. Fixes #4751. R=ken2 CC=golang-dev, lvd https://golang.org/cl/7303043
-
- 20 Dec, 2012 1 commit
-
-
Rémy Oudompheng authored
A fatal error used to happen when escassign-ing a multiple function return to a single node. However, the situation naturally appears when using "go f(g())" or "defer f(g())", because g() is escassign-ed to sink. Fixes #4529. R=golang-dev, lvd, minux.ma, rsc CC=golang-dev https://golang.org/cl/6920060
-
- 29 Oct, 2012 1 commit
-
-
Luuk van Dijk authored
includes step 0: synthesize outparams, from 6600044 includes step 1,2: give outparams loopdepth 0 and verify unchanged results generate esc:$mask tags, but still tie to sink if a param has mask != 0 from 6610054 adds final steps: - have esccall generate n->escretval, a list of nodes the function results flow to - use these in esccall and ORETURN/OAS2FUNC/and f(g()) - only tie parameters to sink if tag is absent, otherwise according to mask, tie them to escretval R=rsc, bradfitz CC=dave, gobot, golang-dev, iant, rsc https://golang.org/cl/6741044
-
- 24 Sep, 2012 1 commit
-
-
Russ Cox authored
Was not handling &x.y[0] and &x.y.z correctly where y is an array or struct-valued field (not a pointer). R=ken2 CC=golang-dev https://golang.org/cl/6551059
-
- 23 Sep, 2012 1 commit
-
-
Russ Cox authored
Today, if run.go doesn't understand a test header line it just ignores the test, making it too easy to write or edit tests that are not actually being run. - expand errorcheck to accept flags, so that bounds.go and escape*.go can run. - create a whitelist of skippable tests in run.go; skipping others is an error. - mark all skipped tests at top of file. Update #4139. R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/6549054
-
- 31 Aug, 2012 1 commit
-
-
Rémy Oudompheng authored
Fixes #3975. R=rsc, lvd CC=golang-dev, remy https://golang.org/cl/6475061
-
- 23 Apr, 2012 1 commit
-
-
Luuk van Dijk authored
Fixes #3545. R=rsc CC=golang-dev https://golang.org/cl/6061043
-
- 24 Feb, 2012 1 commit
-
-
Russ Cox authored
R=ken2 CC=golang-dev, lvd https://golang.org/cl/5693056
-
- 19 Feb, 2012 1 commit
-
-
Rob Pike authored
R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/5656103
-
- 12 Jan, 2012 1 commit
-
-
Rémy Oudompheng authored
The escape analysis code does not make a distinction between scalar and pointers fields in structs. Non-pointer fields that escape should not make the whole struct escape. R=lvd, rsc CC=golang-dev, remy https://golang.org/cl/5489128
-
- 11 Jan, 2012 1 commit
-
-
Russ Cox authored
R=lvd, r CC=golang-dev https://golang.org/cl/5531058
-
- 15 Dec, 2011 1 commit
-
-
Luuk van Dijk authored
This avoids degraded performance caused by extra labels emitted by inlining (breaking strconv ftoa alloc count unittest) and is better in any case. R=rsc CC=golang-dev https://golang.org/cl/5483071
-
- 02 Dec, 2011 1 commit
-
-
Russ Cox authored
R=ken2 CC=golang-dev https://golang.org/cl/5450071
-