- 05 Jan, 2018 8 commits
-
-
Russ Cox authored
If a benchmark calls b.Log without failing (without b.Error/b.Fatal/b.FailNow) then that turns into output very much like a test passing, except it says BENCH instead of PASS. Benchmarks failing say FAIL just like tests failing. Fixes #23346. Change-Id: Ib188e695952da78057ab4a13f90d49937aa3c232 Reviewed-on: https://go-review.googlesource.com/86396 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Hana Kim authored
Fixes #23108 Change-Id: I9b3d0f0c399c0b4cb488adaf3c002bc55d5d21d9 Reviewed-on: https://go-review.googlesource.com/84795Reviewed-by: Heschi Kreinick <heschi@google.com>
-
Russ Cox authored
It is natural for tools to take a large string concatenation like "1" + "1" + "1" + ... + "1" and translate that into a sequence of go/constant calls: x := constant.MakeString("1") x = constant.BinaryOp(x, token.ADD, constant.MakeString("1")) x = constant.BinaryOp(x, token.ADD, constant.MakeString("1")) x = constant.BinaryOp(x, token.ADD, constant.MakeString("1")) x = constant.BinaryOp(x, token.ADD, constant.MakeString("1")) ... If the underlying representation of a string constant is a Go string, then this leads to O(N²) memory for the concatenation of N strings, allocating memory for "1", "11", "111", "1111", and so on. This makes go/types and in particular cmd/vet run out of memory (or at least use far too much) on machine-generated string concatenations, such as those generated by go-bindata. This CL allows code like the above to operate efficiently, by delaying the evaluation of the actual string constant value until it is needed. Now the representation of a string constant is either a string or an explicit addition expression. The addition expression is turned into a string the first time it is requested and then cached for future use. This slows down the use of single strings, but analyses are likely not dominated by that use anyway. It speeds up string concatenations, especially large ones, significantly. On my Mac running 32-bit code: name old time/op new time/op delta StringAdd/1-8 160ns ± 2% 183ns ± 1% +13.98% (p=0.000 n=10+10) StringAdd/4-8 650ns ± 1% 927ns ± 4% +42.73% (p=0.000 n=10+10) StringAdd/16-8 3.93µs ± 1% 2.78µs ± 2% -29.12% (p=0.000 n=8+9) StringAdd/64-8 37.3µs ± 9% 10.1µs ± 5% -73.06% (p=0.000 n=10+10) StringAdd/256-8 513µs ± 5% 38µs ± 1% -92.63% (p=0.000 n=10+10) StringAdd/1024-8 5.67ms ± 4% 0.14ms ± 2% -97.45% (p=0.000 n=8+10) StringAdd/4096-8 77.1ms ± 9% 0.7ms ± 2% -99.10% (p=0.000 n=10+9) StringAdd/16384-8 1.33s ± 7% 0.00s ±10% -99.64% (p=0.000 n=10+10) StringAdd/65536-8 21.5s ± 4% 0.0s ± 8% -99.89% (p=0.000 n=10+10) name old alloc/op new alloc/op delta StringAdd/1-8 232B ± 0% 256B ± 0% +10.34% (p=0.000 n=10+10) StringAdd/4-8 1.20kB ± 0% 1.24kB ± 0% +3.33% (p=0.000 n=10+10) StringAdd/16-8 14.7kB ± 0% 4.6kB ± 0% -68.87% (p=0.000 n=10+10) StringAdd/64-8 223kB ± 0% 16kB ± 0% -92.66% (p=0.000 n=10+10) StringAdd/256-8 3.48MB ± 0% 0.07MB ± 0% -98.07% (p=0.000 n=10+10) StringAdd/1024-8 55.7MB ± 0% 0.3MB ± 0% -99.53% (p=0.000 n=10+10) StringAdd/4096-8 855MB ± 0% 1MB ± 0% -99.88% (p=0.000 n=10+10) StringAdd/16384-8 13.5GB ± 0% 0.0GB ± 0% -99.97% (p=0.000 n=9+10) StringAdd/65536-8 215GB ± 0% 0GB ± 0% -99.99% (p=0.000 n=10+10) name old allocs/op new allocs/op delta StringAdd/1-8 3.00 ± 0% 3.00 ± 0% ~ (all equal) StringAdd/4-8 9.00 ± 0% 11.00 ± 0% +22.22% (p=0.000 n=10+10) StringAdd/16-8 33.0 ± 0% 25.0 ± 0% -24.24% (p=0.000 n=10+10) StringAdd/64-8 129 ± 0% 75 ± 0% -41.86% (p=0.000 n=10+10) StringAdd/256-8 513 ± 0% 269 ± 0% -47.56% (p=0.000 n=10+10) StringAdd/1024-8 2.05k ± 0% 1.04k ± 0% -49.29% (p=0.000 n=10+10) StringAdd/4096-8 8.19k ± 0% 4.12k ± 0% -49.77% (p=0.000 n=10+10) StringAdd/16384-8 32.8k ± 0% 16.4k ± 0% -49.97% (p=0.000 n=9+10) StringAdd/65536-8 131k ± 0% 66k ± 0% -50.11% (p=0.000 n=10+10) https://perf.golang.org/search?q=upload:20180105.2 Fixes #23348 (originally reported as cmd/vet failures in comments on #23222). This makes constant.Values of Kind String no longer meaningful for ==, which required fixes in go/types. While there, also fix go/types handling of constant.Values of Kind Int (for uint64), Float, and Complex. Change-Id: I80867bc9c4232c5c9b213443ff16645434a68b36 Reviewed-on: https://go-review.googlesource.com/86395 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Russ Cox authored
I marked every test that takes more than 0.5 seconds on my machine as something to run only when not in -short mode, or in -short mode on the beefy linux/amd64, windows/amd64, and darwin/amd64 builders. I also shortened a few needlessly-expensive tests where possible. Cuts the time for go test -short cmd/go from 45s to 15s on my machine. Should help even more on some of our builders and slower user machines. Fixes #23287. Change-Id: I0e36003ef947b0ebe4224a1373731f9fa9216843 Reviewed-on: https://go-review.googlesource.com/86252 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Updates #19943 Change-Id: Iea249be51a7af3264bee9ee2b28dbd91043275fc Reviewed-on: https://go-review.googlesource.com/86375Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Also vendors x/net/http git rev 42fe2e1c for: http2: don't check WriteHeader status if we've already sent the header https://golang.org/cl/86255 Fixes #23010 Change-Id: I4f3dd63acb52d5a34a0350aaf847a7a376d6968f Reviewed-on: https://go-review.googlesource.com/86275Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Fixes #22554 Change-Id: I624f2883489a46d7162c11f489c2f0a0ec5a836f Reviewed-on: https://go-review.googlesource.com/86277Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
The docs were too specific. Make it vaguer. There are conditions for which the Transport will try to reuse a connection anyway, even if the Response Body isn't read to EOF or closed, but we don't need to get into all the details in the docs. Fixes #22954 Change-Id: I3b8ae32aeb1a61b396d0026e129552afbfecceec Reviewed-on: https://go-review.googlesource.com/86276Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 04 Jan, 2018 15 commits
-
-
Russ Cox authored
CL 84735 strengthened the -x test to make sure commands succeed, using set -e, but the gcc flag tests can fail. Change them to say || true. Fixes #23337. Change-Id: I01e4017cb36ceb147b56935c2636de52ce7bdfdb Reviewed-on: https://go-review.googlesource.com/86239Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Burch authored
Follows the wording in RFC4366 more precisely which allows a server to optionally return a "certificate_status" when responding to a client hello containing "status_request" extension. fixes #8549 Change-Id: Ib02dc9f972da185b25554568fe6f8bc411d9c0b7 Reviewed-on: https://go-review.googlesource.com/86115Reviewed-by: Adam Langley <agl@golang.org>
-
Paul PISCUC authored
In the comment of seedPost, the word: condiiton was changed to: condition Change-Id: I8967cc0e9f5d37776bada96cc1443c8bf46e1117 Reviewed-on: https://go-review.googlesource.com/86156Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
The spec refers to a map's key and element types; thus the respective values are "keys" and "elements". Also, a map value is the value of the entire map. Similar fix for channels, where appropriate. Fixes #23254. Change-Id: I6f03ea6d86586c7b0b3e84f0c2e9446b8109fa53 Reviewed-on: https://go-review.googlesource.com/85999Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Fixes #21587. Change-Id: I47eb181d65da67a3b530c7f8acac9c0c619ea474 Reviewed-on: https://go-review.googlesource.com/83796 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
If test case framing appears in ordinary test output, then test2json can get confused. If the fake framing is being saved with t.Logf/t.Errorf/etc then we can already distinguish it from real framing, and the code did. It just forgot to write that framing as output (1-line fix). If the fake framing is being generated by printing directly to stdout/stderr, then test2json will simply get confused. There's not a lot to do at that point (maybe it's even a feature). Fixes #23036. Change-Id: I29449c7ace304172b89d8babe23de507c0500455 Reviewed-on: https://go-review.googlesource.com/86238 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
go test -json was inadvertently disabling caching. Fix that. Fixes #22984. Change-Id: Ic933a8c8ac00ce8253e934766954b1ccc6ac0cec Reviewed-on: https://go-review.googlesource.com/84075 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
If you have a package p1 with an xtest (package p1_test) that imports p2, where p2 itself imports p1, then when trying to do coverage for p1 we need to make sure to recompile p2. The problem was that the overall package import graph looked like: main -> p1_test -> p2 -> p1 Since we were recompiling p1 with coverage, we correctly figured out that because p2 depends on a package being recompiled due to coverage, p2 also needs to be split (forked) to insert the dependency on the modified p1. But then we used the same logic to split p1_test and main, with the effect that the changes to p2 and p1_test and main were lost, since the caller was still holding on to the original main, not the split version. Change the code to treat main and p1_test as "already split" and just update them in place. Fixes #23314. Change-Id: If7edeca6e39cdaeb5b9380d00b0c7d8c5891f086 Reviewed-on: https://go-review.googlesource.com/86237 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Fixes #23180. Change-Id: I52404ee98dcc60b96972d4242c13db0ec4340d0d Reviewed-on: https://go-review.googlesource.com/86235 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
findrunnable loops over allp to check run queues *after* it has dropped its own P. This is unsafe because allp can change when nothing is blocking safe-points. Hence, procresize could change allp concurrently with findrunnable's loop. Beyond generally violating Go's memory model, in the best case this could findrunnable to observe a nil P pointer if allp has been grown but the new slots not yet initialized. In the worst case, the reads of allp could tear, causing findrunnable to read a word that isn't even a valid *P pointer. Fix this by taking a snapshot of the allp slice header (but not the backing store) before findrunnable drops its P and iterating over this snapshot. The actual contents of allp are immutable up to len(allp), so this fixes the race. Updates #23098 (may fix). Change-Id: I556ae2dbfffe9fe4a1bf43126e930b9e5c240ea8 Reviewed-on: https://go-review.googlesource.com/86215 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Agniva De Sarker authored
Updates #23332 Change-Id: I964d36ed751ef1844ab6c40f61047297ff1443a3 Reviewed-on: https://go-review.googlesource.com/85797Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Hiroshi Ioka authored
Update rewrite algorithm by coping code from go/internal/work/buildid:updateBuildID. Probably, this is not the best option. We could provide high-level API in cmd/internal/buildid in the future. Fixes #23181 Change-Id: I336a7c50426ab39bc9998b55c372af61a4fb21a7 Reviewed-on: https://go-review.googlesource.com/84735Reviewed-by: Russ Cox <rsc@golang.org>
-
Hana Kim authored
After 1.10, gcflags apply to only the immediate target. Change-Id: I3bf331c76041e7b533076cb2f3274e44aafff58a Reviewed-on: https://go-review.googlesource.com/84775Reviewed-by: Heschi Kreinick <heschi@google.com>
-
Ian Lance Taylor authored
Fixes #23328 Change-Id: Ie4864d7f388d363860318fe41431d8a9719e9a75 Reviewed-on: https://go-review.googlesource.com/86075 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
In func TestXxxx(*testing.T) the Xxxx can be anything that can appear in an identifier, but can't start with a lowercase letter. Clarify the docs. Fixes #23322 Change-Id: I5c297916981f7e3890ee955d12bc7422a75488e2 Reviewed-on: https://go-review.googlesource.com/86001Reviewed-by: Rob Pike <r@golang.org>
-
- 03 Jan, 2018 8 commits
-
-
Ian Lance Taylor authored
Fixes #22349 Change-Id: I84ec4fa9fa95bac0f26bf4ca3e62a35dff4f7e00 Reviewed-on: https://go-review.googlesource.com/86015 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
CL 78735 description: time: add space padding layout strings(using underscore) for not only day but others As mentioned in #22802, only day component of layout string has space padding(represented by one underscore before its placeholder). This commit expands the rule for month, hour, minute and second. Updates #22802 (maybe fixes it) Revert this CL because it breaks currently working formats that happen to use underscores. Fixes #23259 Change-Id: I64acaaca9b5b74785ee0f0be7910574e87daa649 Reviewed-on: https://go-review.googlesource.com/85998 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Ian Lance Taylor authored
I don't know why these errors occur. Ignore them to avoid breaking the build. Updates #22019 Change-Id: Ia048e6d9b928e8e237b311ff3a364e7a23af4aa4 Reviewed-on: https://go-review.googlesource.com/86000 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
We retrieve an error using getsockopt with SO_ERROR. We were reporting the error as coming from "getsockopt", but really it is coming from "connect". It is not getsockopt that failed. Fixes #19302 Change-Id: I510ab76e4b04c70cd9dfdfc46d9a410bf653d017 Reviewed-on: https://go-review.googlesource.com/85997 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Fixes #23146 Change-Id: I06e3328ecca5e27f8e1ada05c2d7cd9bdda714e6 Reviewed-on: https://go-review.googlesource.com/85996 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Commit c2c07c79 (CL 49331) changed the linker and runtime to always use 2MB stacks on 64-bit Windows. This is the corresponding change to make 32-bit Windows always use large (1MB) stacks because it's difficult to detect when Windows applications will call into arbitrary C code that may expect a large stack. This is done as a separate change because it's possible this will cause too much address space pressure for a 32-bit address space. On the other hand, cgo binaries on Windows already use 1MB stacks and there haven't been complaints. Updates #20975. Change-Id: I8ce583f07cb52254fb4bd47250f1ef2b789bc490 Reviewed-on: https://go-review.googlesource.com/49610 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
Daniel Theophanes authored
During the refactor in 1126d148 I introduced a logical error within one withLock function that used the result of the call before checking for the error. Change the order so that the error is checked before the result is used. None of the other withLock uses have similar issues. Fixes #23208 Change-Id: I6c5dcf262e36bad4369c850f1e0131066360a82e Reviewed-on: https://go-review.googlesource.com/85175 Run-TryBot: Daniel Theophanes <kardianos@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Caleb Spare <cespare@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Change-Id: I84fd3912163ca262df5d7d4690c0dd7e136e79ca Reviewed-on: https://go-review.googlesource.com/85938Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 02 Jan, 2018 4 commits
-
-
Cherry Zhang authored
A Select Op could produce a value with upper 32 bits NOT zeroed, for example, Div32 is lowered to (Select0 (DIVL x y)). In theory, we could look into the argument of a Select to decide whether the upper bits are zeroed. As it is late in release cycle, just disable this optimization for Select for now. Fixes #23305. Change-Id: Icf665a2af9ccb0a7ba0ae00c683c9e349638bf85 Reviewed-on: https://go-review.googlesource.com/85736 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
-
Caio Marcelo de Oliveira Filho authored
Modify the regex in TestLinuxSendfile to not match the parameters of the syscall, just its name and the opening parenthesis. This is enough to recognize that the syscall was invoked. This fixes the TestLinuxSendfile test when running in Clear Linux, where strace always execute with -yy implied, having output with extra information in the parameters: [pid 5336] sendfile(6<TCP:[127.0.0.1:35007->127.0.0.1:55170]>, 8</home/c/src/go/src/net/http/testdata/index.html>, NULL, 22) = 22 Change-Id: If7639b785d5fdf65fae8e6149a97a57b06ea981c Reviewed-on: https://go-review.googlesource.com/85657Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brian Kessler authored
Fixes #23224 The previous Pow code had an optimization for powers equal to ±0.5 that used Sqrt for increased accuracy/speed. This caused special cases involving powers of ±0.5 to disagree with the Pow spec. This change places the Sqrt optimization after all of the special case handling. Change-Id: I6bf757f6248256b29cc21725a84e27705d855369 Reviewed-on: https://go-review.googlesource.com/85660Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Tim Cooper authored
Fixes #6535 Change-Id: I34974c0050424c96d19ad69bf4522bb69cde2fd5 Reviewed-on: https://go-review.googlesource.com/85815Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 01 Jan, 2018 1 commit
-
-
Brad Fitzpatrick authored
Change-Id: Ie167512e000f3a8be0ff8a6a9edd52bd74f45115 Reviewed-on: https://go-review.googlesource.com/85775Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
-
- 31 Dec, 2017 2 commits
-
-
Filippo Valsorda authored
Change-Id: I3ff478912a5a178492d544d2f4ee9cc7570d9acc Reviewed-on: https://go-review.googlesource.com/84475Reviewed-by: Filippo Valsorda <hi@filippo.io> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Igor Vashyst authored
Change-Id: If0d9ff107fc6bbdf0231cd48abc23a44816bfe77 Reviewed-on: https://go-review.googlesource.com/85755Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 30 Dec, 2017 1 commit
-
-
Brad Fitzpatrick authored
Fixes #23277 Change-Id: Idbe09913c95dc951b9b195eb7ff1e75d2bb4d63d Reviewed-on: https://go-review.googlesource.com/85675Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 27 Dec, 2017 1 commit
-
-
Cherry Zhang authored
Pick up CL 85476 to fix #23237. Updates #23237. Change-Id: I31a48ef39ce90bc1424334762452281ae706d273 Reviewed-on: https://go-review.googlesource.com/85495Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-