- 16 May, 2019 4 commits
-
-
Russ Cox authored
Add information about action and build IDs, commands run, time spent in commands, and overall time to -debug-actiongraph output. Also avoid a terrible outcome in: go build -debug-actiongraph x.go Change-Id: I7a3a638f4848d75f2bdc997517f4ab23656da4f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/177138 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
The work of running full vet on std and cmd during local development has moved to go test, which of course runs during all.bash. For errors in other GOOS/GOARCH combinations, the misc-compile builders (running buildall.bash) also now run go vet std cmd. The vetall builder need not do anything anymore. Make it a no-op until it can be retired, and remove cmd/vet/all and its special case in the go command. Fixes #31916. Change-Id: I8f30d184c382ea7c2c8f520e5618f680db633968 Reviewed-on: https://go-review.googlesource.com/c/go/+/176440 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Now that the main tree complies with 'go vet', enable all vet checks during 'go test' in the main tree. This helps surface helpful errors while developing, instead of having to wait for the misc-vet-vetall builder. During 'go test', the additional vet checks are essentially free: the vet invocations themselves take only 8 seconds total for the entire tree. Also update buildall.bash (used by the misc-compile builders) to run 'go vet std cmd' for each GOOS/GOARCH pair. This is not as free, since in general it can require recompiling packages with their tests included before invoking vet. (That compilation was going on anyway in the 'go test' case.) On my Mac laptop, ./buildall.bash freebsd used to take 68+16+17+18 = 119 seconds for make.bash and then the builds of the three freebsd architectures. Now it takes 68+16+23+17+23+18+24 = 189 seconds, 60% longer. Some of this is spent doing unnecessary cgo work. Still, this lets us shard the vet checks and match all.bash. Fixes #20119. For #31916. Change-Id: I6b0c40bac47708a688463c7fca12c0fc23ab2751 Reviewed-on: https://go-review.googlesource.com/c/go/+/176439 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
This updates the Go function declarations to match race_amd64.s. Change-Id: I2b541a6b335ce732f4c31652aa615240ce7bb1c3 Reviewed-on: https://go-review.googlesource.com/c/go/+/177397 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
- 15 May, 2019 8 commits
-
-
Damien Neil authored
When fmt.Errorf is provided with a %w verb with an error operand, return an error implementing an Unwrap method returning that operand. It is invalid to use %w with other formatting functions, to use %w multiple times in a format string, or to use %w with a non-error operand. When the Errorf format string contains an invalid use of %w, the returned error does not implement Unwrap. Change-Id: I534e20d3b163ab22c2b137b1c9095906dc243221 Reviewed-on: https://go-review.googlesource.com/c/go/+/176998Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
-
Damien Neil authored
Reverts the following changes: https://go.googlesource.com/go/+/1f90d081391d4f5911960fd28d81d7ea5e554a8f https://go.googlesource.com/go/+/8bf18b56a47a98b9dd2fa03beb358312237a8c76 https://go.googlesource.com/go/+/5402854c3557f87fa2741a52ffc15dfb1ef333cc https://go.googlesource.com/go/+/37f84817247d3b8e687a701ccb0d6bc7ffe3cb78 https://go.googlesource.com/go/+/6be6f114e0d483a233101a67c9644cd72bd3ae7a Partially reverts the followinng change, removing the errors.Opaque function and the errors.Wrapper type definition: https://go.googlesource.com/go/+/62f5e8156ef56fa61e6af56f4ccc633bde1a9120 Updates documentation referencing the Wrapper type. Change-Id: Ia622883e39cafb06809853e3fd90b21441124534 Reviewed-on: https://go-review.googlesource.com/c/go/+/176997 Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
-
Filippo Valsorda authored
Based on RFC 8410. Updates #25355 Change-Id: If7abb7eeb0ede10a9bb3d2004f2116e587c6207a Reviewed-on: https://go-review.googlesource.com/c/go/+/175478 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
Joel Sing authored
This allows the use of CLONE_VFORK and CLONE_VM for fork/exec, preventing "fork/exec ...: cannot allocate memory" failures from occuring when attempting to execute commands from a Go process that has a large memory footprint. Additionally, this should reduce the latency of fork/exec on these platforms. The same problem was addressed on linux/amd64 via issue #5838. Updates #31936 Change-Id: I7ae0fbbeaa29cab944a49a11272a380d497eb2d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/175697 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Vet needs export data for the imports of the package it is analyzing. Vet does not need export data for the package itself, since vet will do its own type checking. Assuming that vet is just as good as the compiler at detecting invalid programs, don't run the compiler unnecessarily. This especially matters for tests without external test files or for which the external test files do not import the test-augmented original package. In that case, the test-augmented original package need not be compiled at all. Cuts time for 'go clean -cache && go vet -x cmd/compile/internal/ssa' from 7.6r 24.3u 2.8s to 3.5r 8.5u 1.9s, by not running the compiler on the augmented test package. There is still more to be done here - if we do need to build a test-augmented package, we rerun cgo unnecessarily. But this is a big help. Cuts time for 'go vet std cmd' by about 30%. For #31916. Change-Id: If6136b4d384f1da77aed90b43f1a6b95f09b5d86 Reviewed-on: https://go-review.googlesource.com/c/go/+/176438 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Picks up vet fix from CL 176357. Change-Id: Ia77cd4a582c4edfbe59bbc311e6ce14046df0e83 Reviewed-on: https://go-review.googlesource.com/c/go/+/177137 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Sylvain Zimmer authored
For many patterns we can compute the minimum input length at compile time. If the input is shorter, we can return early and get a huge speedup. As pointed out by Damian Gryski, Perl's regex engine contains a number of these kinds of fail-fast optimizations: https://perldoc.perl.org/perlreguts.html#Peep-hole-Optimisation-and-Analysis Benchmarks: (including new ones for compile time) name old time/op new time/op delta Compile/Onepass-8 4.39µs ± 1% 4.40µs ± 0% +0.34% (p=0.029 n=9+8) Compile/Medium-8 9.80µs ± 0% 9.91µs ± 0% +1.17% (p=0.000 n=10+10) Compile/Hard-8 72.7µs ± 0% 73.5µs ± 0% +1.10% (p=0.000 n=9+10) name old time/op new time/op delta Match/Easy0/16-8 52.6ns ± 5% 4.9ns ± 0% -90.68% (p=0.000 n=10+9) Match/Easy0/32-8 64.1ns ±10% 61.4ns ± 1% ~ (p=0.188 n=10+9) Match/Easy0/1K-8 280ns ± 1% 277ns ± 2% -0.97% (p=0.004 n=10+10) Match/Easy0/32K-8 4.61µs ± 1% 4.55µs ± 1% -1.49% (p=0.000 n=9+10) Match/Easy0/1M-8 229µs ± 0% 226µs ± 1% -1.29% (p=0.000 n=8+10) Match/Easy0/32M-8 7.50ms ± 1% 7.47ms ± 1% ~ (p=0.165 n=10+10) Match/Easy0i/16-8 533ns ± 1% 5ns ± 2% -99.07% (p=0.000 n=10+10) Match/Easy0i/32-8 950ns ± 0% 950ns ± 1% ~ (p=0.920 n=10+9) Match/Easy0i/1K-8 27.5µs ± 1% 27.5µs ± 0% ~ (p=0.739 n=10+10) Match/Easy0i/32K-8 1.13ms ± 0% 1.13ms ± 1% ~ (p=0.079 n=9+10) Match/Easy0i/1M-8 36.7ms ± 2% 36.1ms ± 0% -1.64% (p=0.000 n=10+9) Match/Easy0i/32M-8 1.17s ± 0% 1.16s ± 1% -0.80% (p=0.004 n=8+9) Match/Easy1/16-8 55.5ns ± 6% 4.9ns ± 1% -91.19% (p=0.000 n=10+9) Match/Easy1/32-8 58.3ns ± 8% 56.6ns ± 1% ~ (p=0.449 n=10+8) Match/Easy1/1K-8 750ns ± 0% 748ns ± 1% ~ (p=0.072 n=8+10) Match/Easy1/32K-8 31.8µs ± 0% 31.6µs ± 1% -0.50% (p=0.035 n=10+9) Match/Easy1/1M-8 1.10ms ± 1% 1.09ms ± 0% -0.95% (p=0.000 n=10+9) Match/Easy1/32M-8 35.5ms ± 0% 35.2ms ± 1% -1.05% (p=0.000 n=9+10) Match/Medium/16-8 442ns ± 2% 5ns ± 1% -98.89% (p=0.000 n=10+10) Match/Medium/32-8 875ns ± 0% 878ns ± 1% ~ (p=0.071 n=9+10) Match/Medium/1K-8 26.1µs ± 0% 25.9µs ± 0% -0.64% (p=0.000 n=10+10) Match/Medium/32K-8 1.09ms ± 1% 1.08ms ± 0% -0.84% (p=0.000 n=10+9) Match/Medium/1M-8 34.9ms ± 0% 34.6ms ± 1% -0.98% (p=0.000 n=9+10) Match/Medium/32M-8 1.12s ± 1% 1.11s ± 1% -0.98% (p=0.000 n=10+9) Match/Hard/16-8 721ns ± 1% 5ns ± 0% -99.32% (p=0.000 n=10+9) Match/Hard/32-8 1.32µs ± 1% 1.31µs ± 0% -0.71% (p=0.000 n=9+9) Match/Hard/1K-8 39.8µs ± 1% 39.7µs ± 1% ~ (p=0.165 n=10+10) Match/Hard/32K-8 1.57ms ± 0% 1.56ms ± 0% -0.70% (p=0.000 n=10+9) Match/Hard/1M-8 50.4ms ± 1% 50.1ms ± 1% -0.57% (p=0.007 n=10+10) Match/Hard/32M-8 1.62s ± 1% 1.60s ± 0% -0.98% (p=0.000 n=10+10) Match/Hard1/16-8 3.88µs ± 1% 3.86µs ± 0% ~ (p=0.118 n=10+10) Match/Hard1/32-8 7.44µs ± 1% 7.46µs ± 1% ~ (p=0.109 n=10+10) Match/Hard1/1K-8 232µs ± 1% 229µs ± 1% -1.31% (p=0.000 n=10+9) Match/Hard1/32K-8 7.41ms ± 2% 7.41ms ± 0% ~ (p=0.237 n=10+8) Match/Hard1/1M-8 238ms ± 1% 238ms ± 0% ~ (p=0.481 n=10+10) Match/Hard1/32M-8 7.69s ± 1% 7.61s ± 0% -1.00% (p=0.000 n=10+10) Fixes #31329 Change-Id: I04640e8c59178ec8b3106e13ace9b109b6bdbc25 Reviewed-on: https://go-review.googlesource.com/c/go/+/171023Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Baokun Lee authored
Now renameio package creates file use ioutil.TempFile, which calls OpenFile with mode 0600, we should support creates a file with given permission bits. Fixes #31871 Change-Id: I0436e9f7081f2fce18bf9f3b14d55b02d4d995fb Reviewed-on: https://go-review.googlesource.com/c/go/+/175958 Run-TryBot: Baokun Lee <nototon@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
- 14 May, 2019 14 commits
-
-
Robert Griesemer authored
The spec was not very precise as to what happens with respect to sharing if a sliced operand is (a pointer to) an array. Added a small clarification and a supporting example. Fixes #31689. Change-Id: Ic49351bec2033abd3f5428154ec3e9a7c2c9eaa5 Reviewed-on: https://go-review.googlesource.com/c/go/+/177139Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Brad Fitzpatrick authored
Updates #30316 Change-Id: I57e489f6bbe4a3b39c907dabe5ac41fb9939cdb4 Reviewed-on: https://go-review.googlesource.com/c/go/+/163477 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
Iskander Sharipov authored
Use objabi.Hlinux for now. Fixes #32028 Change-Id: If9745f72c0ee4444ea2a2faa50813d2e1ac2bf97 Reviewed-on: https://go-review.googlesource.com/c/go/+/177077Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
David Chase authored
This reduces allocations and also resolves some lurking inliner/inlinee line-number match problems. However, it does add about 1.5% to compile time. This fixes compiler OOMs seen compiling some large protobuf- derived inputs. For compiling the compiler itself, compilebench -pkg cmd/compile/internal/ssa -memprofile withcl.prof the numberlines-related memory consumption is reduced from 129MB to 29MB (about a 5% overall reduction in allocation). Additionally modified after going over changes with Austin to remove unused code (nobody called size()) and correct the cache-clearing code. I've attempted to speed this up by not using maps, and have not succeeded. I'd rather get correct code in now, speed it up later if I can. Updates #27739. Fixes #29279. Change-Id: I098005de4e45196a5f5b10c0886a49f88e9f8fd5 Reviewed-on: https://go-review.googlesource.com/c/go/+/154617 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Keith Randall authored
If a slice's entries are sparse, we decide to initialize it dynamically instead of statically. That's CL 151319. But if we do initialize it dynamically, we still need to initialize the static entries. Typically we do that, but the bug fixed here is that we don't if the entry's value is itself an array or struct. To fix, use initKindLocalCode to ensure that both static and dynamic entries are initialized via code. Fixes #31987 Change-Id: I1192ffdbfb5cd50445c1206c4a3d8253295201dd Reviewed-on: https://go-review.googlesource.com/c/go/+/176904 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Brad Fitzpatrick authored
Change-Id: I5db429c86e01b55ec3abc6ab4ca11c221b27f189 Reviewed-on: https://go-review.googlesource.com/c/go/+/177039Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
-
Jonathon Lacher authored
In the reverseproxy, replace use (Header).Get, which returns only one value of a multiple value header, with using the Header map directly. Also fixes corresponding tests which hid the bug, and adds more tests. Fixes #30303 Change-Id: Ic9094b5983043460697748759f6dfd95fc111db7 GitHub-Last-Rev: b41038143f602d4286cb46c542d40de02e6e639d GitHub-Pull-Request: golang/go#30687 Reviewed-on: https://go-review.googlesource.com/c/go/+/166298 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #31950 Change-Id: Id9bcd51a8b49523eeecbd0d8d527372a0b8d8760 Reviewed-on: https://go-review.googlesource.com/c/go/+/177038 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Clément Chigot authored
The memory might not be synchronized in a thread being woken up after a semasleep. Using atomic instructions in noteclear function will force this synchronisation. Fixes #30189 Change-Id: If7432f29b2a1a56288231822db52f3f8d1d6dbfe Reviewed-on: https://go-review.googlesource.com/c/go/+/163624 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
LE Manh Cuong authored
Fixes #14683 Change-Id: I62c429e4fcc2f20a94d3db8c1f0ca587252c07a7 Reviewed-on: https://go-review.googlesource.com/c/go/+/174130 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Bryan C. Mills authored
Some repositories include tags like 'v1.0.0-rc.1+oryOS.9'. If we were to allow such tags, they could become ambiguous: semantic versioning defines versions that differ only in metadata to have equal precedence, so if someone added a tag 'v1.0.0-rc.1+other' at a different commit, then the version 'v1.0.0-rc.1' would become ambiguous. However, we should still allow those tags to be used to resolve versions, and since we can even parse the underlying semantic version, we can at least use that as the basis for a unique (and well-ordered) pseudo-version. Fixes #31713 Change-Id: I5035f76d74ead6e786c04a368595cb5e42d36f91 Reviewed-on: https://go-review.googlesource.com/c/go/+/176905 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
Fixes #31972 Change-Id: I3bb9ef3a1134e67d2d062bea2f0e4032647e12e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/176898 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Bryan C. Mills authored
Fixes #31857 Change-Id: Ib0b791376acb7ee1cdc163f808b8ecf77dbdaf06 Reviewed-on: https://go-review.googlesource.com/c/go/+/176580 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Bjørn Erik Pedersen authored
Before this commit, the two logically equivalent conditionals below would produce different output: {{ if not .NonEmptyInterfaceTypedNil }}OK{{ else }}{{ end }} {{ if .NonEmptyInterfaceTypedNil }}{{ else }}OK{{ end }} The functions `not`, `or`, and `and` all use the same `truth` function, which unwraps any concrete interface value before passing it to `isTrue`. `if` and `with` also use `isTrue` to establish truth, but was missing the interface indirect call. Fixes #30501 Change-Id: I9c49eed41e737d8f162e39bef1c3b82fd5518fed GitHub-Last-Rev: 95fc2c82f26d24a457de4deaa7e5756718fbf07c GitHub-Pull-Request: golang/go#30534 Reviewed-on: https://go-review.googlesource.com/c/go/+/164958Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>
-
- 13 May, 2019 14 commits
-
-
Robert Griesemer authored
Add a small paragraph and example pointing out the difference for the case where T is a slice or map. This is a common error for Go novices. Fixes #29425. Change-Id: Icdb59f25361e9f6a09b190fbfcc9ae0c7d90077b Reviewed-on: https://go-review.googlesource.com/c/go/+/176338Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
The very first paragraph on "Package initialization" stated that "variables are initialized in declaration order, but after any variables they might depend on". This phrasing was easily misread as "declaration order is the first sorting criteria" and then contradicted what the subsequent paragraphs spelled out in precise detail. Instead, variable initialization proceeds by repeatedly determining a set of ready to initialize variables, and then selecting from that set the variable declared earliest. That is, declaration order is the second sorting criteria. Also, for the purpose of variable initialization, declarations introducing blank (_) variables are considered like any other variables (their initialization expressions may have side-effects and affect initialization order), even though blank identifiers are not "declared". This CL adds clarifying language regarding these two issues and the supporting example. Both gccgo and go/types implement this behavior. cmd/compile has a long-standing issue (#22326). The spec also did not state in which order multiple variables initialized by a single (multi-value) initialization expression are handled. This CL adds a clarifying paragraph: If any such variable is initialized, all that declaration's variables are initialized at the same time. This behavior matches user expectation: We are not expecting to observe partially initialized sets of variables in declarations such as "var a, b, c = f()". It also matches existing cmd/compile and go/types (but not gccgo) behavior. Finally, cmd/compile, gccgo, and go/types produce different initialization orders in (esoteric) cases where hidden (not detected with existing rules) dependencies exist. Added a sentence and example clarifying how much leeway compilers have in those situations. The goal is to preserve the ability to use static initialization while at the same time maintain the relative initialization order of variables with detected dependencies. Fixes #31292. Updates #22326. Change-Id: I0a369abff8cfce27afc975998db875f5c580caa2 Reviewed-on: https://go-review.googlesource.com/c/go/+/175980Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Josh Bleecher Snyder authored
Reduces the time on my machine for go clean -cache; go test -short -count=1 cmd/compile/internal/gc from 4.7s to 3.7s. Updates #26473 Change-Id: I9f9573675ffd6519da63961f48f61260ae4717fd Reviewed-on: https://go-review.googlesource.com/c/go/+/176937 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
This fixes test failures introduced by CL 176901. Change-Id: I133299ba3be3a15ced076c95e4833ba6070d7eb7 Reviewed-on: https://go-review.googlesource.com/c/go/+/176903 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
This speeds up go test -short -count=1 cmd/fix on my machine from about 8s to about 0.05s. Updates #26473 Change-Id: I698ee20704ae0aee874ba642e7b0e070ddc99194 Reviewed-on: https://go-review.googlesource.com/c/go/+/176900 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Tamir Duberstein authored
These were added in https://go-review.googlesource.com/1224; according to austin@google.com these annotations are not valuable - resolving by removing the TODOs. Change-Id: Icf3f21bc385cac9673ba29f0154680e970cf91f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/176899Reviewed-by: Austin Clements <austin@google.com>
-
Jay Conrod authored
This is a follow-up to CL 174099, fixing an important TODO. The 'go help modget' documentation will be clarified in anotehr CL, pending further discussion. When invoked without -m, 'go get' will no longer match arguments containing "..." against module paths. If a module's path matches a pattern but no packages within the module match the pattern, the module should not be upgraded. For example, if golang.org/x/tools/playground and golang.org/x/tools are separate modules, and only golang.org/x/tools is in the build list, 'go get golang.org/x/tools/playground/...' should add golang.org/x/tools/playground to the build list and leave golang.org/x/tools alone. Updates #26902 Change-Id: I2bd18c7950db1aa7bd8527210c1baf2c7d174375 Reviewed-on: https://go-review.googlesource.com/c/go/+/176578 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Josh Bleecher Snyder authored
Speeds up go test -short -count=1 cmd/objdump on my machine from 1.7s to 1.3s. Not much, but as the backpacking saying goes, take care of the ounces and the pounds will take care of themselves. Updates #26473 Change-Id: I59fe9a179e48537c7d82cbba72cde9f92b42a029 Reviewed-on: https://go-review.googlesource.com/c/go/+/176901 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Luka Zitnik authored
Fixes #30507 Change-Id: Ic598e4d5f71c624fcde051982bf85533e2f18e8d Reviewed-on: https://go-review.googlesource.com/c/go/+/170948Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cherry Zhang authored
MOVBstore's value argument is a value, not a flag. We are storing a byte so just use UInt8. Fixes #31915. Change-Id: Id799e5f44efc3a9c3d8480f6f25ad032c2a631bb Reviewed-on: https://go-review.googlesource.com/c/go/+/176719 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Keith Randall <khr@golang.org>
-
Russ Cox authored
This CL changes the index/suffixarray construction algorithm from QSufSort to SAIS. For an N-byte input, QSufSort runs in O(N log N) time and requires an N-int temporary work space in addition to the N-int output. In contrast, SAIS runs in O(N) time and, for essentially all real inputs, is able to use the N-int output buffer as its temporary work space. (In pathological cases, SAIS must allocate a temporary work space of at most N/2 ints. There exist more complex variants that guarantee to avoid the work space in all cases, but they hardly seem worth the cost given how rare these pathological cases are.) The SAIS code therefore uses 50% of the memory across the board. It also runs 3-10X faster on real input text. This CL also adds more extensive algorithmic tests, including an exhaustive test over small inputs to catch corner case problems. name old speed new speed delta New/text=opticks/size=100K/bits=32-12 6.15MB/s ± 1% 26.79MB/s ± 1% +335.89% (p=0.008 n=5+5) New/text=opticks/size=100K/bits=64-12 5.90MB/s ± 2% 27.29MB/s ± 2% +362.23% (p=0.008 n=5+5) New/text=opticks/size=500K/bits=32-12 4.99MB/s ± 3% 25.37MB/s ± 2% +408.01% (p=0.008 n=5+5) New/text=opticks/size=500K/bits=64-12 4.88MB/s ± 1% 25.66MB/s ± 4% +425.52% (p=0.008 n=5+5) New/text=go/size=100K/bits=32-12 5.81MB/s ± 1% 26.49MB/s ± 2% +355.85% (p=0.008 n=5+5) New/text=go/size=100K/bits=64-12 5.76MB/s ± 2% 26.65MB/s ± 3% +362.60% (p=0.008 n=5+5) New/text=go/size=500K/bits=32-12 4.91MB/s ± 1% 25.12MB/s ± 2% +411.86% (p=0.008 n=5+5) New/text=go/size=500K/bits=64-12 4.83MB/s ± 2% 25.79MB/s ± 2% +434.44% (p=0.008 n=5+5) New/text=go/size=1M/bits=32-12 4.62MB/s ± 2% 24.87MB/s ± 2% +438.78% (p=0.008 n=5+5) New/text=go/size=1M/bits=64-12 4.39MB/s ± 2% 24.61MB/s ± 2% +460.68% (p=0.008 n=5+5) New/text=go/size=5M/bits=32-12 2.85MB/s ± 2% 24.78MB/s ± 7% +768.33% (p=0.008 n=5+5) New/text=go/size=5M/bits=64-12 2.28MB/s ± 1% 18.70MB/s ± 7% +719.63% (p=0.008 n=5+5) New/text=go/size=10M/bits=32-12 2.08MB/s ± 1% 21.04MB/s ± 6% +909.60% (p=0.008 n=5+5) New/text=go/size=10M/bits=64-12 1.83MB/s ± 1% 16.64MB/s ± 2% +809.18% (p=0.008 n=5+5) New/text=go/size=50M/bits=32-12 1.51MB/s ± 0% 10.58MB/s ± 1% +602.52% (p=0.008 n=5+5) New/text=go/size=50M/bits=64-12 1.34MB/s ± 4% 9.00MB/s ± 1% +569.35% (p=0.008 n=5+5) New/text=zero/size=100K/bits=32-12 4.17MB/s ± 0% 157.56MB/s ± 1% +3678.42% (p=0.016 n=4+5) New/text=zero/size=100K/bits=64-12 4.19MB/s ± 2% 162.72MB/s ± 2% +3783.63% (p=0.008 n=5+5) New/text=zero/size=500K/bits=32-12 3.72MB/s ± 5% 159.17MB/s ± 1% +4176.57% (p=0.008 n=5+5) New/text=zero/size=500K/bits=64-12 3.77MB/s ± 3% 164.95MB/s ± 4% +4277.60% (p=0.008 n=5+5) New/text=zero/size=1M/bits=32-12 3.46MB/s ± 3% 158.42MB/s ± 1% +4476.08% (p=0.008 n=5+5) New/text=zero/size=1M/bits=64-12 3.41MB/s ± 4% 163.70MB/s ± 2% +4700.65% (p=0.008 n=5+5) New/text=zero/size=5M/bits=32-12 3.12MB/s ± 2% 151.92MB/s ± 4% +4775.48% (p=0.008 n=5+5) New/text=zero/size=5M/bits=64-12 3.09MB/s ± 2% 166.19MB/s ± 2% +5274.84% (p=0.008 n=5+5) New/text=zero/size=10M/bits=32-12 2.97MB/s ± 1% 157.75MB/s ± 1% +5211.38% (p=0.008 n=5+5) New/text=zero/size=10M/bits=64-12 2.92MB/s ± 1% 162.75MB/s ± 2% +5473.77% (p=0.008 n=5+5) New/text=zero/size=50M/bits=32-12 2.67MB/s ± 1% 144.43MB/s ± 5% +5305.39% (p=0.008 n=5+5) New/text=zero/size=50M/bits=64-12 2.61MB/s ± 1% 125.19MB/s ± 2% +4700.33% (p=0.016 n=5+4) New/text=rand/size=100K/bits=32-12 8.69MB/s ± 6% 27.60MB/s ± 1% +217.73% (p=0.008 n=5+5) New/text=rand/size=100K/bits=64-12 8.92MB/s ± 1% 26.37MB/s ± 4% +195.50% (p=0.008 n=5+5) New/text=rand/size=500K/bits=32-12 7.11MB/s ± 2% 25.23MB/s ± 2% +254.78% (p=0.008 n=5+5) New/text=rand/size=500K/bits=64-12 7.08MB/s ± 1% 25.45MB/s ± 2% +259.56% (p=0.008 n=5+5) New/text=rand/size=1M/bits=32-12 6.45MB/s ± 2% 24.47MB/s ± 3% +279.11% (p=0.008 n=5+5) New/text=rand/size=1M/bits=64-12 6.09MB/s ± 4% 23.00MB/s ± 4% +277.85% (p=0.008 n=5+5) New/text=rand/size=5M/bits=32-12 3.68MB/s ± 3% 10.34MB/s ± 5% +181.08% (p=0.008 n=5+5) New/text=rand/size=5M/bits=64-12 3.25MB/s ± 1% 6.23MB/s ± 1% +91.93% (p=0.008 n=5+5) New/text=rand/size=10M/bits=32-12 3.03MB/s ± 1% 5.61MB/s ± 2% +85.28% (p=0.008 n=5+5) New/text=rand/size=10M/bits=64-12 2.80MB/s ± 1% 4.29MB/s ± 2% +53.40% (p=0.008 n=5+5) New/text=rand/size=50M/bits=32-12 2.11MB/s ± 0% 2.45MB/s ± 1% +16.23% (p=0.029 n=4+4) New/text=rand/size=50M/bits=64-12 2.04MB/s ± 1% 2.24MB/s ± 1% +10.03% (p=0.016 n=5+4) SaveRestore/bits=32-12 327MB/s ± 5% 319MB/s ± 2% ~ (p=0.310 n=5+5) SaveRestore/bits=64-12 306MB/s ± 3% 306MB/s ± 2% ~ (p=0.841 n=5+5) name old alloc/op new alloc/op delta New/text=opticks/size=100K/bits=32-12 811kB ± 0% 401kB ± 0% -50.51% (p=0.008 n=5+5) New/text=opticks/size=100K/bits=64-12 1.62MB ± 0% 0.80MB ± 0% -50.51% (p=0.008 n=5+5) New/text=opticks/size=500K/bits=32-12 4.04MB ± 0% 2.01MB ± 0% -50.37% (p=0.008 n=5+5) New/text=opticks/size=500K/bits=64-12 8.07MB ± 0% 4.01MB ± 0% -50.36% (p=0.016 n=4+5) New/text=go/size=100K/bits=32-12 811kB ± 0% 401kB ± 0% ~ (p=0.079 n=4+5) New/text=go/size=100K/bits=64-12 1.62MB ± 0% 0.80MB ± 0% -50.50% (p=0.008 n=5+5) New/text=go/size=500K/bits=32-12 4.04MB ± 0% 2.01MB ± 0% ~ (p=0.079 n=4+5) New/text=go/size=500K/bits=64-12 8.07MB ± 0% 4.01MB ± 0% -50.36% (p=0.000 n=4+5) New/text=go/size=1M/bits=32-12 8.07MB ± 0% 4.01MB ± 0% -50.36% (p=0.008 n=5+5) New/text=go/size=1M/bits=64-12 16.1MB ± 0% 8.0MB ± 0% -50.36% (p=0.008 n=5+5) New/text=go/size=5M/bits=32-12 40.2MB ± 0% 20.0MB ± 0% -50.18% (p=0.008 n=5+5) New/text=go/size=5M/bits=64-12 80.3MB ± 0% 40.0MB ± 0% -50.18% (p=0.008 n=5+5) New/text=go/size=10M/bits=32-12 80.2MB ± 0% 40.0MB ± 0% -50.09% (p=0.000 n=5+4) New/text=go/size=10M/bits=64-12 160MB ± 0% 80MB ± 0% -50.09% (p=0.000 n=5+4) New/text=go/size=50M/bits=32-12 402MB ± 0% 200MB ± 0% -50.29% (p=0.000 n=5+4) New/text=go/size=50M/bits=64-12 805MB ± 0% 400MB ± 0% -50.29% (p=0.000 n=5+4) New/text=zero/size=100K/bits=32-12 1.46MB ± 0% 0.40MB ± 0% -72.46% (p=0.008 n=5+5) New/text=zero/size=100K/bits=64-12 3.02MB ± 0% 0.80MB ± 0% -73.45% (p=0.008 n=5+5) New/text=zero/size=500K/bits=32-12 8.66MB ± 0% 2.01MB ± 0% ~ (p=0.079 n=4+5) New/text=zero/size=500K/bits=64-12 19.7MB ± 0% 4.0MB ± 0% -79.63% (p=0.008 n=5+5) New/text=zero/size=1M/bits=32-12 19.7MB ± 0% 4.0MB ± 0% ~ (p=0.079 n=4+5) New/text=zero/size=1M/bits=64-12 39.0MB ± 0% 8.0MB ± 0% -79.48% (p=0.000 n=5+4) New/text=zero/size=5M/bits=32-12 85.2MB ± 0% 20.0MB ± 0% -76.52% (p=0.008 n=5+5) New/text=zero/size=5M/bits=64-12 169MB ± 0% 40MB ± 0% -76.27% (p=0.008 n=5+5) New/text=zero/size=10M/bits=32-12 169MB ± 0% 40MB ± 0% -76.26% (p=0.000 n=5+4) New/text=zero/size=10M/bits=64-12 333MB ± 0% 80MB ± 0% -75.99% (p=0.008 n=5+5) New/text=zero/size=50M/bits=32-12 739MB ± 0% 200MB ± 0% -72.93% (p=0.000 n=4+5) New/text=zero/size=50M/bits=64-12 1.63GB ± 0% 0.40GB ± 0% -75.42% (p=0.008 n=5+5) New/text=rand/size=100K/bits=32-12 807kB ± 0% 401kB ± 0% -50.25% (p=0.008 n=5+5) New/text=rand/size=100K/bits=64-12 1.61MB ± 0% 0.80MB ± 0% -50.25% (p=0.008 n=5+5) New/text=rand/size=500K/bits=32-12 4.04MB ± 0% 2.01MB ± 0% ~ (p=0.079 n=4+5) New/text=rand/size=500K/bits=64-12 8.07MB ± 0% 4.01MB ± 0% ~ (p=0.079 n=4+5) New/text=rand/size=1M/bits=32-12 8.07MB ± 0% 4.01MB ± 0% -50.36% (p=0.000 n=5+4) New/text=rand/size=1M/bits=64-12 16.1MB ± 0% 8.0MB ± 0% -50.36% (p=0.008 n=5+5) New/text=rand/size=5M/bits=32-12 40.3MB ± 0% 20.0MB ± 0% -50.35% (p=0.029 n=4+4) New/text=rand/size=5M/bits=64-12 80.7MB ± 0% 40.0MB ± 0% ~ (p=0.079 n=4+5) New/text=rand/size=10M/bits=32-12 80.7MB ± 0% 40.0MB ± 0% -50.41% (p=0.008 n=5+5) New/text=rand/size=10M/bits=64-12 161MB ± 0% 80MB ± 0% -50.44% (p=0.029 n=4+4) New/text=rand/size=50M/bits=32-12 403MB ± 0% 200MB ± 0% -50.36% (p=0.000 n=5+4) New/text=rand/size=50M/bits=64-12 806MB ± 0% 400MB ± 0% ~ (p=0.079 n=4+5) SaveRestore/bits=32-12 5.28MB ± 0% 5.28MB ± 0% ~ (p=1.000 n=5+5) SaveRestore/bits=64-12 9.47MB ± 0% 9.47MB ± 0% ~ (p=0.286 n=5+5) https://perf.golang.org/search?q=upload:20190426.1 Fixes #15480. Change-Id: I0790f6edf67f5a9c02b4462632b4942e0c37988b Reviewed-on: https://go-review.googlesource.com/c/go/+/174100 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Eric Roshan-Eisner <edre@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Tamir Duberstein authored
This was left over from the C->Go transition. Change-Id: I52494af3d49a388dc45b57210ba68292ae01cf84 Reviewed-on: https://go-review.googlesource.com/c/go/+/176897 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Bryan C. Mills authored
Fixes #31965 Change-Id: I2126903196b630c0bee2c022be1a818e0856ce3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176539 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Bryan C. Mills authored
Use cfg.GOSUMDB consistently instead of re-resolving it from the environment. Set cfg.GOSUMDB to 'off' explicitly in coderepo_test, since it may include modules that cannot be fetched using a released version of the 'go' command. Fixes #31964 Change-Id: I17cae9e0c6aa1168ba534e6da4e3652800ac81e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/176538 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-