- 20 Aug, 2018 12 commits
-
-
Ben Shi authored
Those new instructions have acquire/release semantics, besides normal atomic SWPD/SWPW/SWPH/SWPB. Change-Id: I24821a4d21aebc342897ae52903aef612c8d8a4a Reviewed-on: https://go-review.googlesource.com/128476 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Ben Shi authored
Since MULA&MULS cost more CPU cycles than MUL, so MUL Rx, Ry, Rd CMP Ra, Rd cost less cycles than MULA Rx, Ry, Ra, Rd CMP $0, Rd This CL implement that optimization, and the GobEncode-4 of the go1 benchmark got a little improvement, while other cases got little impact (noise excluded). name old time/op new time/op delta BinaryTree17-4 25.2s ± 1% 25.2s ± 0% ~ (p=0.420 n=30+29) Fannkuch11-4 13.3s ± 0% 13.3s ± 0% +0.03% (p=0.003 n=27+30) FmtFprintfEmpty-4 406ns ± 0% 405ns ± 0% ~ (p=0.309 n=30+30) FmtFprintfString-4 672ns ± 0% 670ns ± 0% -0.32% (p=0.000 n=29+29) FmtFprintfInt-4 717ns ± 0% 714ns ± 0% -0.42% (p=0.000 n=27+22) FmtFprintfIntInt-4 1.07µs ± 0% 1.07µs ± 0% +0.11% (p=0.000 n=19+30) FmtFprintfPrefixedInt-4 1.12µs ± 0% 1.12µs ± 0% -0.43% (p=0.000 n=23+30) FmtFprintfFloat-4 2.25µs ± 0% 2.25µs ± 0% ~ (p=0.509 n=29+29) FmtManyArgs-4 4.01µs ± 1% 4.00µs ± 0% -0.35% (p=0.000 n=30+30) GobDecode-4 53.6ms ± 4% 51.9ms ± 2% -3.17% (p=0.000 n=30+30) GobEncode-4 51.1ms ± 2% 50.6ms ± 2% -0.98% (p=0.000 n=30+30) Gzip-4 2.61s ± 0% 2.61s ± 0% ~ (p=0.504 n=30+30) Gunzip-4 312ms ± 0% 312ms ± 0% ~ (p=0.866 n=30+30) HTTPClientServer-4 977µs ± 7% 974µs ± 8% ~ (p=0.804 n=30+29) JSONEncode-4 127ms ± 1% 125ms ± 2% -1.88% (p=0.000 n=29+29) JSONDecode-4 435ms ± 3% 431ms ± 2% -0.80% (p=0.005 n=30+30) Mandelbrot200-4 18.4ms ± 0% 18.4ms ± 0% -0.02% (p=0.006 n=29+25) GoParse-4 22.4ms ± 0% 22.4ms ± 0% ~ (p=0.105 n=27+29) RegexpMatchEasy0_32-4 753ns ± 0% 753ns ± 0% ~ (all equal) RegexpMatchEasy0_1K-4 4.32µs ± 0% 4.32µs ± 0% ~ (p=0.554 n=29+28) RegexpMatchEasy1_32-4 788ns ± 0% 788ns ± 0% ~ (all equal) RegexpMatchEasy1_1K-4 5.54µs ± 0% 5.55µs ± 0% +0.03% (p=0.013 n=29+30) RegexpMatchMedium_32-4 1.08µs ± 0% 1.08µs ± 0% ~ (p=0.443 n=28+28) RegexpMatchMedium_1K-4 258µs ± 0% 258µs ± 0% ~ (p=0.932 n=30+28) RegexpMatchHard_32-4 14.8µs ± 0% 14.8µs ± 0% -0.06% (p=0.021 n=30+30) RegexpMatchHard_1K-4 442µs ± 0% 442µs ± 0% ~ (p=0.554 n=29+30) Revcomp-4 41.7ms ± 1% 41.7ms ± 1% ~ (p=0.763 n=28+30) Template-4 528ms ± 1% 528ms ± 0% ~ (p=0.072 n=30+29) TimeParse-4 3.31µs ± 0% 3.31µs ± 0% ~ (p=0.215 n=30+30) TimeFormat-4 6.07µs ± 0% 6.07µs ± 0% ~ (p=0.733 n=30+30) [Geo mean] 386µs 385µs -0.29% name old speed new speed delta GobDecode-4 14.3MB/s ± 4% 14.8MB/s ± 2% +3.23% (p=0.000 n=30+30) GobEncode-4 15.0MB/s ± 2% 15.2MB/s ± 2% +0.99% (p=0.000 n=30+30) Gzip-4 7.44MB/s ± 0% 7.44MB/s ± 0% ~ (p=0.328 n=29+30) Gunzip-4 62.2MB/s ± 0% 62.2MB/s ± 0% ~ (p=0.905 n=30+30) JSONEncode-4 15.2MB/s ± 1% 15.5MB/s ± 2% +1.93% (p=0.000 n=29+29) JSONDecode-4 4.46MB/s ± 3% 4.50MB/s ± 2% +0.79% (p=0.007 n=30+30) GoParse-4 2.58MB/s ± 1% 2.58MB/s ± 1% ~ (p=0.223 n=29+30) RegexpMatchEasy0_32-4 42.5MB/s ± 0% 42.5MB/s ± 0% ~ (p=0.964 n=30+30) RegexpMatchEasy0_1K-4 237MB/s ± 0% 237MB/s ± 0% ~ (p=0.392 n=29+28) RegexpMatchEasy1_32-4 40.6MB/s ± 0% 40.6MB/s ± 0% ~ (p=0.974 n=30+29) RegexpMatchEasy1_1K-4 185MB/s ± 0% 185MB/s ± 0% -0.03% (p=0.012 n=29+30) RegexpMatchMedium_32-4 920kB/s ± 0% 920kB/s ± 0% ~ (all equal) RegexpMatchMedium_1K-4 3.97MB/s ± 0% 3.97MB/s ± 0% ~ (all equal) RegexpMatchHard_32-4 2.17MB/s ± 0% 2.17MB/s ± 0% +0.18% (p=0.000 n=30+28) RegexpMatchHard_1K-4 2.32MB/s ± 0% 2.32MB/s ± 0% ~ (all equal) Revcomp-4 61.0MB/s ± 1% 61.0MB/s ± 1% ~ (p=0.744 n=28+30) Template-4 3.68MB/s ± 1% 3.67MB/s ± 0% ~ (p=0.147 n=30+29) [Geo mean] 12.7MB/s 12.7MB/s +0.41% Change-Id: Ic6053c350c94e9bf57db16542e1370b848155342 Reviewed-on: https://go-review.googlesource.com/129535 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ben Shi authored
FLD1 pushes +1.0 to the 387 register stack, and FLDZ pushes +0.0 to the 387 regiser stack. They can be used to simplify MOVSSconst/MOVSDconst when the constant is +0.0, -0.0, +1.0, -1.0. The size of the go executable reduces about 62KB and the total size of pkg/linux_386 reduces about 7KB with this optimization. Change-Id: Icc8213b58262e0024a277cf1103812a17dd4b05e Reviewed-on: https://go-review.googlesource.com/119635 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Yury Smolsky authored
Change-Id: Id87d9f55d1714fc553f5b1a9cba0f2fe348dad3e Reviewed-on: https://go-review.googlesource.com/126396 Run-TryBot: Yury Smolsky <yury@smolsky.by> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Daniel Martí authored
Two funcs and a field were unused. Remove them. A few statements could be made simpler. importsym's pos parameter was unused, so remove it. Finally, don't use printf-like funcs with constant strings that have no formatting directives. Change-Id: I415452249bf2168aa353ac4f3643dfc03017ee53 Reviewed-on: https://go-review.googlesource.com/117699 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Daniel Martí authored
Issues #10043, #15405, and #22660 appear to have been fixed, and whatever tests I could run locally do succeed, so remove the skips. Issue #7237 was closed in favor of #17906, so update its skip line. Issue #7634 was closed as it had not appeared for over three years. Re-enable it for now. An issue should be open if the test starts being skipped again. Change-Id: I67daade906744ed49223291035baddaad9f56dca Reviewed-on: https://go-review.googlesource.com/121735 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
To report the capacity of the underlying buffer. The method mirrors bytes.Buffer.Cap. The method can be useful to know whether or not calling write or grow methods will result in an allocation, or to know how much memory has been allocated so far. Fixes #26269. Change-Id: I391db45ae825011566b594836991e28135369a78 Reviewed-on: https://go-review.googlesource.com/122835 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
This lets us simplify the code considerably. For example, unquoting the tag is no longer necessary, and we can get the field name with a single method call. While at it, fix a typechecking error in testdata/structtag.go, which hadn't been caught since vet still skips past go/types errors in most cases. Using go/types will also let us expand the structtag check more easily if we want to, for example to allow it to check for duplicates in embedded fields. Finally, update one of the test cases to check for regressions when we output invalid tag strings. We also checked that these two changes to testdata/structtag.go didn't fail with the old structtag check. For #25593. Change-Id: Iea4906d0f30a67f36b28c21d8aa96251aae653f5 Reviewed-on: https://go-review.googlesource.com/115676 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Alan Donovan <adonovan@google.com> Reviewed-by:
Rob Pike <r@golang.org>
-
Tobias Klauser authored
Port CL 120295 from golang.org/x/sys/unix to the syscall package. The ustat syscall has been deprecated on Linux for a long time and the upcoming glibc 2.28 will remove ustat.h and it can no longer be used to to generate the Ustat_t wrapper type. Since Linux still provides the syscall, let's not break this functionality and add a private copy of struct ustat so Ustat_t can still be generated. Fixes golang/go#25990 Change-Id: I0dab2ba1cc76fbd21553b499f9256fd9d59ca409 Reviewed-on: https://go-review.googlesource.com/120563 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Iskander Sharipov authored
Combined appends lead to fewer machine code and faster performance. Some may even say that it makes code more readable. Running revAddrTests over reverseaddr gives measurable improvements: name old time/op new time/op delta ReverseAddress-8 4.10µs ± 3% 3.94µs ± 1% -3.81% (p=0.000 n=10+9) Change-Id: I9bda7a20f802bcdffc6e948789765d04c6da04e7 Reviewed-on: https://go-review.googlesource.com/117615 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
-
Daniel Martí authored
These are all errors given by module-aware cmd/go, so they must end with a newline. It looks like they were omitted by mistake. Fixes #27081. Change-Id: I19b5803bb48a6d5dd52e857f483278fe20fe246b Reviewed-on: https://go-review.googlesource.com/129780 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Change-Id: I5f887f9831378cf76f5a9f447f481ea24c63f390 Reviewed-on: https://go-review.googlesource.com/129803Reviewed-by:
-
- 18 Aug, 2018 8 commits
-
-
Russ Cox authored
Need to actually use the flag for it to take effect. Fixes #27049. Change-Id: I57227b45f46f9dd67ecbf87c11bb2d08124bcfa0 Reviewed-on: https://go-review.googlesource.com/129801 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
It was a bug to find that commit in the Masterminds/semver repo. It's not part of the main repo but only part of an unmerged pull request. The code was updated to try not to look at unmerged pull requests, but the test was not. Worse, whether the code succeeds at not looking at unmerged pull requests apparently depends on the git version. Sigh. Fixes #26754. Fixes #27043. Change-Id: Ib9e07f565906de4f1169244911a258396688f14d Reviewed-on: https://go-review.googlesource.com/129800 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Fixes #27066. Change-Id: Iede4385ad86b42d7d90814965b161a7e64d29833 Reviewed-on: https://go-review.googlesource.com/129799 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
In GOPATH mode the rule has always been that 'go run x.go' can import whatever the package in x.go's directory would be able to import. Apply the same rule here. The bad import path was triggering other mysterious errors during 'go run' in other circumstances. Setting it correctly fixes those too. Fixes #26046. Fixes #27022. Change-Id: I0a9b0a154a20f48add5a199da85572e7ffe0cde4 Reviewed-on: https://go-review.googlesource.com/129798 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
This is an important security problem so we shouldn't disable the test. The second half was failing on case-sensitive file systems but the first half is still good. Fixes #22983. Change-Id: I437bb4c9f78eb3177aa8b619e2357b2539566ca9 Reviewed-on: https://go-review.googlesource.com/129797 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
If you run go get -u github.com/rsc/foo/bar... then the go get command has always worked hard to make sure that it applies the wildcard after downloading rsc/foo. (If it applied the wildcard only before downloading rsc/foo, it would match nothing if you had an empty GOPATH before, and you'd still have an empty afterward, which is clearly useless.) The goal has always been that if you run the same go get command twice, the second command doesn't find anything new to do. CL 19892 worked around an "internal error" failure but broke the rule about the first command doing everything the second command would. Suppose you had github.com/rsc/foo already, with just github.com/rsc/foo/bar, and you run go get -u github.com/rsc/... The wildcard first matches github.com/rsc/foo/bar, but suppose updating the repo pulls down github.com/rsc/foo/baz, which in turn depends on the non-existent package github.com/rsc/quux. We need to reevaluate the wildcard after the download. The new pattern match refactoring makes this easier and happened to have corrected the behavior, but we missed a long test that expected the old behavior. Fix that long test. Change-Id: I088473e7a90925e5c0f9697da9554a11456ddd08 Reviewed-on: https://go-review.googlesource.com/129796 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
If we're looking for a module for a/b/c/d/e, we check for a module named a/b/c/d/e, then a/b/c/d, then a/b/c, then a/b, then a. If we know the source repo for a/b/c and that fails, we should report that error instead of continuing the loop: a/b and a are useless, and the error from a/b/c contains important information. The errors are now a bit more verbose than I'd like but they will suffice for Go 1.11. $ go get github.com/bradfitz/private/sonos go get github.com/bradfitz/private/sonos: git ls-remote -q origin in /Users/rsc/pkg/mod/cache/vcs/61e3c76780847e514802ec6af8f940f641c6017f711444f05c59cb17ac46d456: exit status 128: remote: Repository not found. fatal: repository 'https://github.com/bradfitz/private/' not found $ go list launchpad.net/gocheck can't load package: package launchpad.net/gocheck: unknown import path "launchpad.net/gocheck": bzr branch --use-existing-dir https://launchpad.net/~niemeyer/gocheck/trunk . in /Users/rsc/pkg/mod/cache/vcs/f46ce2ae80d31f9b0a29099baa203e3b6d269dace4e5357a2cf74bd109e13339: exec: "bzr": executable file not found in $PATH $ Fixes #26885. Fixes #26982. Change-Id: I2f9cf1853d2d68af18adad668c80513b6ba220d6 Reviewed-on: https://go-review.googlesource.com/129683 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
"go mod fix" does work already done by nearly every other go command. It was also confusing why we had both "go mod fix" and "go mod tidy". Delete "go mod fix". The main reason we kept "go mod fix" this long was for the discussion of automatic go.mod updates in its documentation, which is now moved into a new "go help go.mod". Fixes #26831. Change-Id: Ic95ca8918449ab79791d27998e02eb3377ac7972 Reviewed-on: https://go-review.googlesource.com/129682 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 17 Aug, 2018 14 commits
-
-
Russ Cox authored
The proxy protocol was simplified to only send (and only receive) the Path and Version fields in the JSON blob, not Name and Short. (Those make sense when querying a VCS repo directly, but not when talking about extracted modules.) So don't expect them in the test. Fixes #27042. Change-Id: I3daacd668126e2227dcc8e6b89ee0cf0e3c8497c Reviewed-on: https://go-review.googlesource.com/129684 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David du Colombier authored
CL 129063 added a test in TestScript/mod_enabled, which was failing on Plan 9. The test was failing because the Init function of the cmd/go/internal/modload package was expecting ModRoot to be part of os.TempDir. However, ModRoot was set to TMPDIR, while os.TempDir is returning /tmp on Plan 9. This change fixes the implementation of os.TempDir on Plan 9 to handle the TMPDIR environment variable, similarly to Unix. Fixes #27065. Change-Id: Id6ff926c5c379f63cab2dfc378fa6c15293fd453 Reviewed-on: https://go-review.googlesource.com/129775Reviewed-by:
-
Russ Cox authored
If you're in a directory corresponding to x/y and you run go list ./z, we do at some point want to turn that into x/y/z. But if ./z does not exist that will make the go command check the network to see if it can find x/y/z. That's clearly wrong: ./z means that directory, nothing else. And it turns a typo into a long delay, which is even worse. Fixes #26874. Change-Id: Iec15fa7b359af11b6a4fc6cb082e593658fb6e41 Reviewed-on: https://go-review.googlesource.com/129061 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
It's important for some uses of go/packages, as well as for some of go/packages's internal use, to be able to tell which results from go list output correspond to which patterns, keeping in mind that a single package might have been matched by multiple patterns. Also adds test for #26925. Change-Id: I708ac162f65d9946fe6afb244b08dc7b04d2b530 Reviewed-on: https://go-review.googlesource.com/129060 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
A flag setting like -gcflags=-e applies only to the packages named on the command line, not to their dependencies. The way we used to implement this was to remember the command line arguments, reinterpret them as pattern matches instead of package argument generators (globs), and apply them during package load. The reason for this complexity was to address a command-line like: go build -gcflags=-e fmt runtime The load of fmt will load dependencies, including runtime, and the load of runtime will reuse the result of the earlier load. Because we were computing the effective -gcflags for each package during the load, we had to have a way to tell, when encountering runtime during the load of fmt, that runtime had been named on the command line, even though we hadn't gotten that far. That would be easy if the only possible arguments were import paths, but we also need to handle go build -gcflags=-e fmt runt... go build -gcflags=-e fmt $GOROOT/src/runtime go build -gcflags=-e fmt $GOROOT/src/runt... and so on. The match predicates usually did their job well, but not always. In particular, thanks to symlinks and case-insensitive file systems and unusual ways to spell file paths, it's always been possible in various corner cases to give an argument that evalutes to the runtime package during loading but failed to match it when reused to determine "was this package named on the command line?" CL 109235 fixed one instance of this problem by making a directory pattern match case-insensitive on Windows, but that is incorrect in some other cases and doesn't address the root problem, namely that there will probably always be odd corner cases where pattern matching and pattern globbing are not exactly aligned. This CL eliminates the assumption that pattern matching and pattern globbing are always completely in agreement, by simply marking the packages named on the command line after the package load returns them. This means delaying the computation of tool flags until after the load too, for a few different ways packages are loaded. The different load entry points add some complexity, which is why the original approach seemed more attractive, but the original approach had complexity that we simply didn't recognize at the time. This CL then rolls back the CL 109235 pattern-matching change, but it keeps the test introduced in that CL. That test still passes. In addition to fixing ambiguity due to case-sensitive file systems, this new approach also very likely fixes various ambiguities that might arise from abuse of symbolic links. Fixes #24232. Fixes #24456. Fixes #24750. Fixes #25046. Fixes #25878. Change-Id: I0b09825785dfb5112fb11494cff8527ebf57966f Reviewed-on: https://go-review.googlesource.com/129059 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
To date the go command has always just treated the command line package patterns as a []string, expanded by pattern matching into another []string. As a result, the code is not always clear about whether a particular []string contains patterns or results. A few different important bugs are caused by not keeping this distinction clear enough. This CL sets us up well for fixing those, by introducing an explicit search.Match struct holding the results of matching a single pattern. The added clarity here also makes it clear how to avoid duplicate warnings about unmatched packages. Fixes #26925. (Test in followup CL.) Change-Id: Ic2f0606f7ab8b3734a40e22d3cb1e6f58d031061 Reviewed-on: https://go-review.googlesource.com/129058 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Alan Donovan authored
Also, rename an HTML element ID to avoid duplicate. Fixes golang/go#27038 Change-Id: Icc064a1cc86ddc794fc085d98b4cde3effff8ad0 Reviewed-on: https://go-review.googlesource.com/129635Reviewed-by:
Andrew Bonventre <andybons@golang.org> Reviewed-by:
Ian Cottrell <iancottrell@google.com>
-
Russ Cox authored
Only the expected headings are affected. Diffing the output of "go run headscan.go" before and after: $ diff head1 head2 26a27,28 > Edit go.mod from tools or scripts > Make go.mod semantically consistent 168c170 < 141 headings found --- > 143 headings found $ Fixes #26938. Change-Id: I204fd982a60773aa26880cd19eed890c373b8ab6 Reviewed-on: https://go-review.googlesource.com/129677 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
It's already half gone and later will be all gone. It's not worth explaining in an introduction doc. Fixes #24506 Updates #4719 Change-Id: Ie48128b3aa090d84e0e734aa45f14a4480292913 Reviewed-on: https://go-review.googlesource.com/129679Reviewed-by:
-
Daniel Martí authored
It is possible to write a function that seems to wrap a print/printf call, but then doesn't. For example, if the string parameter we thought was the format is used as another argument. One option would be to make vet's print analysis smarter, to detect when format strings are indeed used like we initially suspected. However, I've opted for a simpler solution - check if the print/printf call is already using more than one variadic argument, in which case using an ellipsis in the last one would break the program: // too many arguments in call to fmt.Printf fmt.Printf(format, arg0, args...) Fixes #26979. Change-Id: I39371f1cec8483cfd2770a91670c1e80cbb9efdf Reviewed-on: https://go-review.googlesource.com/129575 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Dan Johnson authored
Ranging through a map is non-deterministic and there can be duplicate entries in the set (with the same name) which don't have identical definitions in some cases. Fixes #27013 Change-Id: I378c48bc359c10b25b9238e0c663b498455b19fd Reviewed-on: https://go-review.googlesource.com/129515Reviewed-by:
-
Russ Cox authored
Added this locally but then broke the first rule of Gerrit and clicked Submit instead of running "git submit". Change-Id: I83c28d9151c566e9b2092e2613d67731a5d64beb Reviewed-on: https://go-review.googlesource.com/129678 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
Obviously, including files that import "C" when cgo is disabled is wrong. The package load step correctly excludes them and finds no files at all, which then causes a failure. Fixes #26927. Change-Id: I00e6d6450e783d467d20bde99e91240ecb0db837 Reviewed-on: https://go-review.googlesource.com/129062 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Bryan C. Mills <bcmills@google.com> Reviewed-by:
David du Colombier <0intro@gmail.com>
-
Russ Cox authored
Two different people have created /tmp/go.mod for experimentation and then had other tests that create fresh work directories below /tmp fail unexpectedly because the go command finds /tmp/go.mod. Refuse to use /tmp/go.mod. /tmp/anything/go.mod is fine. Fixes #26708. Change-Id: I2a4f61ea63099cff59fbf9e8798e5dcefefd5557 Reviewed-on: https://go-review.googlesource.com/129063 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 16 Aug, 2018 3 commits
-
-
Brad Fitzpatrick authored
It seems it might not have ever worked. Updates #22983 Change-Id: Icc022539aa2555486a65900abf97dfa30f92a1ea Reviewed-on: https://go-review.googlesource.com/129615 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
the function libc_errno returns a pointer to a signed-32 bit quantity, not a 64-bit quantity. Fixes #27004 Change-Id: I0623835ee34fd9655532251f096022a5accb58cd Reviewed-on: https://go-review.googlesource.com/129475 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alberto Donizetti authored
mkalldocs.sh was run and it also picked up a doc change introduced in CL 128935, where it wasn't run. Fixes #27030 Change-Id: Ie13fdb71cd7d5481366a02eb711ca48f094026fd Reviewed-on: https://go-review.googlesource.com/129576Reviewed-by:
-
- 14 Aug, 2018 3 commits
-
-
Robert Griesemer authored
In previous versions of Go including 1.10, an empty line would break the alignment of elements within an expression list. golang.org/cl/104755 changed the heuristic, with the side effect that empty lines no longer broke the table alignment. A prior fix (https://go-review.googlesource.com/c/go/+/125260, reverted) introduced another regression (#26930) which this change doesn't produce. Added test cases for both #26352 and #26930. Fixes #26352. Updates #26930. Change-Id: I371f48e6f3620ebbab53f2128ec5e58bcd4a62f1 Reviewed-on: https://go-review.googlesource.com/129256 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Martin Möhrmann authored
Change-Id: I29a6125c9ef285fc365c4e11ab158b79224ae333 Reviewed-on: https://go-review.googlesource.com/126602 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
This reverts commit c116265e. The change, while addressing issue #26352, introduced another regression (#26930), which is worse. Reverting this change in favor of a better fix for the original issue. Updates #26352. Fixes #26930. Change-Id: I71ad12a8212992cce5c1e73907d1f7460f98d9e8 Reviewed-on: https://go-review.googlesource.com/129255 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
