- 11 Oct, 2019 4 commits
-
-
fenos authored
We should keep a consistent way of formatting errors in this file. Fixes #34848 Change-Id: Ibb75908504f381fccab0281a42e788ef8c716b6f Reviewed-on: https://go-review.googlesource.com/c/go/+/200679 Run-TryBot: Johan Brandhorst <johan.brandhorst@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc>
-
davidsbond authored
Fixes #34846 Change-Id: I24b3e65fc96ec85b2821480e9396c9d1663611c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/200678 Run-TryBot: Johan Brandhorst <johan.brandhorst@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Johan Brandhorst <johan.brandhorst@gmail.com>
-
Bryan C. Mills authored
Fixes #34847 Change-Id: Ibb58c8820cdab8b9f3755fcfba754ad0c9ca982f Reviewed-on: https://go-review.googlesource.com/c/go/+/200657 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Elias Naur <mail@eliasnaur.com>
-
Agniva De Sarker authored
Coalesce set/get pairs into a tee. Change-Id: I88ccdcb148465615437bebf24145e941a037e0a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/200357 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Richard Musiol <neelance@gmail.com> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
- 10 Oct, 2019 7 commits
-
-
Brad Fitzpatrick authored
Part 1: CL 199499 (GOOS nacl) Part 2: CL 200077 (amd64p32 files, toolchain) Part 3: stuff that arguably should've been part of Part 2, but I forgot one of my grep patterns when splitting the original CL up into two parts. This one might also have interesting stuff to resurrect for any future x32 ABI support. Updates #30439 Change-Id: I2b4143374a253a003666f3c69e776b7e456bdb9c Reviewed-on: https://go-review.googlesource.com/c/go/+/200318 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Fixes #34768 Change-Id: Ic73591f620cdee5bc7203483902e6ba98d2c442b Reviewed-on: https://go-review.googlesource.com/c/go/+/200438Reviewed-by:
Bryan C. Mills <bcmills@google.com>
-
alan authored
Change-Id: If5a272f331fe9da09467efedd0231a4ce34db0f8 GitHub-Last-Rev: 4b81a79a92db4b51001ce6660b24c760fd3b630b GitHub-Pull-Request: golang/go#28420 Reviewed-on: https://go-review.googlesource.com/c/go/+/144999 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Jay Conrod authored
Also, in cmd/doc, avoid calling 'go list -m all' when in module mode outside a module since it's now an error. Fixes #32027 Change-Id: I7224c7fdf7e950bce6c058ab2a5837c27ba3b899 Reviewed-on: https://go-review.googlesource.com/c/go/+/200297 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jeremy Faller authored
Walking the progs is simpler than using the is_stmt symbol shenanigans. This is a reinstatement of CL 196661, which was rolled back due to tests failing. Unlike that original CL, this change should output the same debug_lines data the original approach wrote. The stats for JUST this CLC, note teh small speedup in compilation, and the lack of difference in binary size. name old time/op new time/op delta Template 229ms ± 4% 218ms ± 1% -4.95% (p=0.000 n=10+8) Unicode 92.6ms ± 9% 88.6ms ±13% ~ (p=0.089 n=10+10) GoTypes 850ms ± 2% 831ms ± 4% -2.23% (p=0.009 n=10+10) Compiler 3.99s ± 1% 3.93s ± 1% -1.29% (p=0.000 n=10+9) SSA 13.7s ± 1% 13.7s ± 1% ~ (p=0.912 n=10+10) Flate 140ms ± 3% 138ms ± 3% -1.90% (p=0.009 n=10+10) GoParser 172ms ± 2% 169ms ± 4% ~ (p=0.095 n=9+10) Reflect 530ms ± 3% 516ms ± 5% ~ (p=0.052 n=10+10) Tar 202ms ± 1% 196ms ± 3% -2.83% (p=0.002 n=9+10) XML 280ms ± 3% 270ms ± 4% -3.48% (p=0.009 n=10+10) LinkCompiler 927ms ± 2% 907ms ± 4% ~ (p=0.052 n=10+10) ExternalLinkCompiler 1.97s ± 2% 1.97s ± 3% ~ (p=0.853 n=10+10) LinkWithoutDebugCompiler 549ms ± 3% 543ms ± 5% ~ (p=0.481 n=10+10) StdCmd 12.0s ± 1% 12.0s ± 1% ~ (p=0.905 n=9+10) name old user-time/op new user-time/op delta Template 372ms ±18% 344ms ±11% ~ (p=0.190 n=10+10) Unicode 264ms ±23% 241ms ±43% ~ (p=0.315 n=8+10) GoTypes 1.56s ±22% 1.68s ± 5% ~ (p=0.237 n=10+8) Compiler 7.41s ± 2% 7.31s ± 3% ~ (p=0.123 n=10+10) SSA 24.5s ± 2% 24.7s ± 1% ~ (p=0.133 n=10+9) Flate 199ms ± 6% 188ms ±28% ~ (p=0.353 n=10+10) GoParser 243ms ±11% 240ms ± 6% ~ (p=0.968 n=10+9) Reflect 929ms ±21% 862ms ±35% ~ (p=0.190 n=10+10) Tar 284ms ± 9% 296ms ±17% ~ (p=0.497 n=9+10) XML 386ms ±21% 398ms ±28% ~ (p=1.000 n=9+10) LinkCompiler 1.13s ± 9% 1.12s ± 8% ~ (p=0.546 n=9+9) ExternalLinkCompiler 2.37s ±15% 2.30s ± 9% ~ (p=0.549 n=10+9) LinkWithoutDebugCompiler 646ms ±10% 642ms ±13% ~ (p=0.853 n=10+10) name old alloc/op new alloc/op delta Template 36.5MB ± 0% 36.5MB ± 0% -0.11% (p=0.000 n=10+9) Unicode 28.5MB ± 0% 28.5MB ± 0% ~ (p=0.190 n=10+10) GoTypes 121MB ± 0% 121MB ± 0% -0.10% (p=0.000 n=9+10) Compiler 549MB ± 0% 549MB ± 0% -0.10% (p=0.000 n=9+10) SSA 1.92GB ± 0% 1.92GB ± 0% -0.13% (p=0.000 n=10+10) Flate 23.0MB ± 0% 23.0MB ± 0% -0.07% (p=0.000 n=10+10) GoParser 27.9MB ± 0% 27.9MB ± 0% -0.09% (p=0.000 n=10+10) Reflect 77.9MB ± 0% 77.8MB ± 0% -0.13% (p=0.000 n=9+10) Tar 34.5MB ± 0% 34.4MB ± 0% -0.09% (p=0.000 n=10+10) XML 44.3MB ± 0% 44.3MB ± 0% -0.08% (p=0.000 n=10+10) LinkCompiler 229MB ± 0% 225MB ± 0% -1.74% (p=0.000 n=10+10) ExternalLinkCompiler 233MB ± 0% 242MB ± 0% +3.81% (p=0.000 n=10+10) LinkWithoutDebugCompiler 156MB ± 0% 152MB ± 0% -2.29% (p=0.000 n=10+9) name old allocs/op new allocs/op delta Template 373k ± 0% 373k ± 0% -0.21% (p=0.000 n=10+10) Unicode 340k ± 0% 340k ± 0% -0.04% (p=0.000 n=10+10) GoTypes 1.33M ± 0% 1.33M ± 0% -0.20% (p=0.000 n=10+9) Compiler 5.39M ± 0% 5.38M ± 0% -0.16% (p=0.000 n=10+10) SSA 18.3M ± 0% 18.2M ± 0% -0.15% (p=0.000 n=10+10) Flate 235k ± 0% 234k ± 0% -0.23% (p=0.000 n=10+7) GoParser 309k ± 0% 308k ± 0% -0.20% (p=0.000 n=10+10) Reflect 970k ± 0% 968k ± 0% -0.30% (p=0.000 n=10+10) Tar 347k ± 0% 347k ± 0% -0.22% (p=0.000 n=10+10) XML 425k ± 0% 424k ± 0% -0.16% (p=0.000 n=10+10) LinkCompiler 602k ± 0% 601k ± 0% -0.03% (p=0.000 n=9+10) ExternalLinkCompiler 1.65M ± 0% 1.65M ± 0% -0.02% (p=0.000 n=10+10) LinkWithoutDebugCompiler 220k ± 0% 220k ± 0% -0.03% (p=0.016 n=10+9) name old object-bytes new object-bytes delta Template 553kB ± 0% 553kB ± 0% -0.01% (p=0.000 n=10+10) Unicode 215kB ± 0% 215kB ± 0% ~ (all equal) GoTypes 2.02MB ± 0% 2.02MB ± 0% -0.00% (p=0.000 n=10+10) Compiler 7.98MB ± 0% 7.98MB ± 0% -0.01% (p=0.000 n=10+10) SSA 27.1MB ± 0% 27.1MB ± 0% -0.00% (p=0.000 n=10+10) Flate 340kB ± 0% 340kB ± 0% -0.01% (p=0.000 n=10+10) GoParser 434kB ± 0% 434kB ± 0% -0.00% (p=0.000 n=10+10) Reflect 1.34MB ± 0% 1.34MB ± 0% -0.01% (p=0.000 n=10+10) Tar 479kB ± 0% 479kB ± 0% -0.00% (p=0.000 n=10+10) XML 618kB ± 0% 618kB ± 0% -0.01% (p=0.000 n=10+10) name old export-bytes new export-bytes delta Template 20.4kB ± 0% 20.4kB ± 0% ~ (all equal) Unicode 8.21kB ± 0% 8.21kB ± 0% ~ (all equal) GoTypes 36.6kB ± 0% 36.6kB ± 0% ~ (all equal) Compiler 116kB ± 0% 116kB ± 0% +0.00% (p=0.000 n=10+10) SSA 141kB ± 0% 141kB ± 0% +0.00% (p=0.000 n=10+10) Flate 5.10kB ± 0% 5.10kB ± 0% ~ (all equal) GoParser 8.92kB ± 0% 8.92kB ± 0% ~ (all equal) Reflect 11.8kB ± 0% 11.8kB ± 0% ~ (all equal) Tar 10.9kB ± 0% 10.9kB ± 0% ~ (all equal) XML 17.4kB ± 0% 17.4kB ± 0% ~ (all equal) name old text-bytes new text-bytes delta HelloSize 742kB ± 0% 742kB ± 0% ~ (all equal) CmdGoSize 10.6MB ± 0% 10.6MB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 10.7kB ± 0% 10.7kB ± 0% ~ (all equal) CmdGoSize 312kB ± 0% 312kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 122kB ± 0% 122kB ± 0% ~ (all equal) CmdGoSize 146kB ± 0% 146kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.10MB ± 0% 1.10MB ± 0% ~ (all equal) CmdGoSize 14.9MB ± 0% 14.9MB ± 0% -0.03% (p=0.000 n=10+10) Change-Id: Ie078a42b29353b96654fa1f0f47d600b5a53762d Reviewed-on: https://go-review.googlesource.com/c/go/+/200017Reviewed-by:
Jeremy Faller <jeremy@golang.org> Reviewed-by:
David Chase <drchase@google.com> Run-TryBot: Jeremy Faller <jeremy@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cuong Manh Le authored
When unmarshaling to a map, the map's key type must either be a string, an integer, or implement encoding.TextUnmarshaler. But for a user defined type, reflect.Kind will not distinguish between the static type and the underlying type. In: var x MyString = "x" t := reflect.TypeOf(x) println(t.Kind() == reflect.String) the Kind of x is still reflect.String, even though the static type of x is MyString. Moreover, checking for the map's key type is a string occurs first, so even if the map key type MyString implements encoding.TextUnmarshaler, it will be ignored. To fix the bug, check for encoding.TextUnmarshaler first. Fixes #34437 Change-Id: I780e0b084575e1dddfbb433fe03857adf71d05fb Reviewed-on: https://go-review.googlesource.com/c/go/+/200237 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Tom Thorogood authored
Compact has been inconsistently escaping only some problematic characters (U+2028 and U+2029), but not others (<, > and &). This change addresses this inconsistency by removing the escaping of U+2028 and U+2029. Callers who need to escape the output of Compact should use HTMLEscape which escapes <, >, &, U+2028 and U+2029. Fixes #34070 Fixes #30357 Updates #5836 Change-Id: Icfce7691d2b8b1d9b05ba7b64d2d1e4f3b67871b GitHub-Last-Rev: 38859fe3e2fd586bbd45175c2742f7b123836bf3 GitHub-Pull-Request: golang/go#34804 Reviewed-on: https://go-review.googlesource.com/c/go/+/200217Reviewed-by:
-
- 09 Oct, 2019 20 commits
-
-
Jay Conrod authored
When in module mode outside of any module, 'go build' and most other commands will now report an error instead of resolving a package path to a module. Previously, most commands would attempt to find the latest version of a module providing the package. This could be very slow if many packages needed to be resolved this way. Since there is no go.mod file where module requirements can be saved, it's a repeatedly slow and confusing experience. After this change, 'go build' and other commands may still be used outside of a module on packages in std and source files (.go arguments) that only import packages in std. Listing any other package on the command line or importing a package outside std will cause an error. 'go get' is exempted from the new behavior, since it's expected that 'go get' resolves paths to modules at new versions. Updates #32027 Change-Id: Ia9d3a3b4ad738ca5423472e17818d62b96a2c959 Reviewed-on: https://go-review.googlesource.com/c/go/+/198778 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jay Conrod authored
Updates #34669 Change-Id: I8d0ee68885e804e131f42a512080486f9b25e9dd Reviewed-on: https://go-review.googlesource.com/c/go/+/199819 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jay Conrod authored
go/build.Import locates package dirctories using 'go list' when in module mode (finding, downloading, and extracting modules is complicated, so go/build does not handle it). Previously, Import used 'go list' if GO111MODULE was not explicitly off and a go.mod file was present (plus some other conditions). With this change, if GO111MODULE is "on", a go.mod file does not need to be present. Fixes #34669 Change-Id: I9e56871054d4b07c3fc04b6f14a5c8c8e9f3c333 Reviewed-on: https://go-review.googlesource.com/c/go/+/199818 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
This is part two if the nacl removal. Part 1 was CL 199499. This CL removes amd64p32 support, which might be useful in the future if we implement the x32 ABI. It also removes the nacl bits in the toolchain, and some remaining nacl bits. Updates #30439 Change-Id: I2475d5bb066d1b474e00e40d95b520e7c2e286e1 Reviewed-on: https://go-review.googlesource.com/c/go/+/200077Reviewed-by:
-
Ainar Garipov authored
Some code tags in the HTML were not properly closed. Close them so that the text is rendered correctly. Change-Id: I5c2170ffced313417f65004d53518128c34f7979 Reviewed-on: https://go-review.googlesource.com/c/go/+/200117Reviewed-by:
-
Jay Conrod authored
This change introduces a new interface, load.ImportPathError. An error may satisfy this by providing an ImportPath method and including the import path in its error text. modload.ImportMissingError satisfies this interface. load.ImportErrorf also provides a convenient way to create an error satisfying this interface with an arbitrary message. When load.PackageError formats its error text, it may omit the last path on the import stack if the wrapped error satisfies ImportPathError and has a matching path. To make this work, PackageError.Err is now an error instead of a string. PackageError.MarshalJSON will write Err as a string for 'go list -json' output. When go/build.Import invokes 'go list' in module mode, it now runs with '-e' and includes '.Error' in the output format instead of expecting the error to be in the raw stderr text. If a package error is printed and a directory was not found, the error will be returned without extra decoration. Fixes #34752 Change-Id: I2d81dab7dec19e0ae9f51f6412bc9f30433a8596 Reviewed-on: https://go-review.googlesource.com/c/go/+/199840 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Bryan C. Mills authored
This reverts CL 184457. Reason for revert: introduced failures in the regression test for #18153. Fixes #34791 Updates #29062 Change-Id: I4040965163f809083c023be055e69b1149d6214e Reviewed-on: https://go-review.googlesource.com/c/go/+/200106 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by:
Alexander Rakoczy <alex@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Jason A. Donenfeld authored
When rewriting a go.mod file, we currently sort all of the require lines in a block. The way the parser works is that it considers preceding blank lines to be empty comment lines, and preceding empty comment lines are "owned" by their adjoining line. So when we go to sort them, the empty lines follow around each sorted entry, which doesn't make a whole lot of sense, since usually vertical space is inserted to show sections, and if things get moved around by sorting, those sections are no longer meaningful. This all results in one especially troublesome edge case: blank lines between a block opening ("require (") and the first block line ("golang.org/x/sys ...") are not treated the same way and are rewritten out of existence. Here's an example of the behavior this fixes. Starting input file: require ( golang.zx2c4.com/wireguard master golang.org/x/crypto latest golang.org/x/net latest golang.org/x/sys latest golang.org/x/text latest github.com/lxn/walk latest github.com/lxn/win latest ) Now we run this through `GOPROXY=direct go get -d`: require ( github.com/lxn/walk v0.0.0-20190619151032-86d8802c197a github.com/lxn/win v0.0.0-20190716185335-d1d36f0e4f48 golang.org/x/crypto v0.0.0-20190820162420-60c769a6c586 golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7 golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a golang.org/x/text v0.3.2 golang.zx2c4.com/wireguard v0.0.20190806-0.20190822065259-3cedc22d7b49 ) Notice how the blank lines before lxn/walk and x/crypto were preserved. Finally, we have this be rewritten yet again with a call to `go build`: require ( github.com/lxn/walk v0.0.0-20190619151032-86d8802c197a github.com/lxn/win v0.0.0-20190716185335-d1d36f0e4f48 golang.org/x/crypto v0.0.0-20190820162420-60c769a6c586 golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7 golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a golang.org/x/text v0.3.2 golang.zx2c4.com/wireguard v0.0.20190806-0.20190822065259-3cedc22d7b49 ) In this final resting point, the first blank line has been removed. The discrepancy between those two last stages are especially bothersome, because it makes for lots of dirty git commits and file contents bouncing back and forth. This commit fixes the problem as mentioned above, getting rid of those preceding blank lines. The output in all cases looks as it should, like this: require ( github.com/lxn/walk v0.0.0-20190619151032-86d8802c197a github.com/lxn/win v0.0.0-20190716185335-d1d36f0e4f48 golang.org/x/crypto v0.0.0-20190820162420-60c769a6c586 golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7 golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a golang.org/x/text v0.3.2 golang.zx2c4.com/wireguard v0.0.20190806-0.20190822065259-3cedc22d7b49 ) Fixes #33779 Change-Id: I11c894440bd35f343ee62db3e06a50fa871f2599 Reviewed-on: https://go-review.googlesource.com/c/go/+/199917 Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Emmanuel T Odeke authored
Updates x/net/http2 to git rev d66e71096ffb9f08f36d9aefcae80ce319de6d68 http2: end stream eagerly after sending the request body https://golang.org/cl/181157 (fixes #32254) all: fix typos https://golang.org/cl/193799 http2: fix memory leak in random write scheduler https://golang.org/cl/198462 (fixes #33812) http2: do not sniff body if Content-Encoding is set https://golang.org/cl/199841 (updates #31753) Also unskips tests from CL 199799. Change-Id: I241c0b1cd18cad5041485be92809137a973e33bd Reviewed-on: https://go-review.googlesource.com/c/go/+/200102 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by:Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Emmanuel T Odeke authored
Fixes #31753 Change-Id: I32ec5906ef6714e19b094f67cb0f10a211a9c500 Reviewed-on: https://go-review.googlesource.com/c/go/+/199799 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Bryan C. Mills authored
Updates #33848 Change-Id: I81663386297282397ce1b546a8b15597bfbcea78 Reviewed-on: https://go-review.googlesource.com/c/go/+/199821 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
This implements the proposal described in https://golang.org/issue/33848#issuecomment-537222782. Fixes #33848 Change-Id: Ia34d6500ca396b6aa644b920233716c6b83ef729 Reviewed-on: https://go-review.googlesource.com/c/go/+/198319 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jay Conrod authored
This functionality already exists but was undocumented. Related to comments in CL 198797. Change-Id: Icce40bd7c362423e6ed9c20673ce3de1311e5fd5 Reviewed-on: https://go-review.googlesource.com/c/go/+/200040 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by:
-
Than McIntosh authored
Test case with code that caused a gccgo error while emitting export data for an inlinable function. Updates #34577. Change-Id: I28b598c4c893c77f4a76bb4f2d27e5b42f702992 Reviewed-on: https://go-review.googlesource.com/c/go/+/198057 Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by:
-
Daniel Martí authored
For example, if a test calls os.Exit(0), that could trick a 'go test' run into not running some of the other tests, and thinking that they all succeeded. This can easily go unnoticed and cause developers headaches. Add a simple sanity check as part of 'go test': if the test binary succeeds and doesn't print anything, we should error, as something clearly went very wrong. This is done by inspecting each of the stdout writes from the spawned process, since we don't want to read the entirety of the output into a buffer. We need to introduce a "buffered" bool var, as there's now an io.Writer layer between cmd.Stdout and &buf. A few TestMain funcs in the standard library needed fixing, as they returned without printing anything as a means to skip testing the entire package. For that purpose add testenv.MainMust, which prints a warning and prints SKIP, similar to when -run matches no tests. Finally, add tests for both os.Exit(0) and os.Exit(1), both as part of TestMain and as part of a single test, and test that the various stdout modes still do the right thing. Fixes #29062. Change-Id: Ic6f8ef3387dfc64e4cd3e8f903d7ca5f5f38d397 Reviewed-on: https://go-review.googlesource.com/c/go/+/184457 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Michael Munday authored
The branch-on-count instructions on s390x decrement the input register and then compare its value to 0. If not equal the branch is taken. These instructions are useful for implementing loops with a set number of iterations (which might be in a register). For example, this for loop: for i := 0; i < n; i++ { ... // i is not used or modified in the loop } Could be implemented using this assembly: MOVD Rn, Ri loop: ... BRCTG Ri, loop Note that i will count down from n in the assembly whereas in the original for loop it counted up to n which is why we can't use i in the loop. These instructions will only be used in hand-written codegen and assembly for now since SSA blocks cannot currently modify values. We could look into this in the future though. Change-Id: Iaab93b8aa2699513b825439b8ea20d8fe2ea1ee6 Reviewed-on: https://go-review.googlesource.com/c/go/+/199977 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Michael Munday authored
The element size for VSUMQF and VSUMQG was off by one. Fix this and add tests for VSUM* instruction encodings. Change-Id: I6de2dabb383e5bc6f85eef1e0f106ba949c9030b Reviewed-on: https://go-review.googlesource.com/c/go/+/199978 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Bryan C. Mills authored
In CL 197059, I suppressed errors if the target package was already found. However, that does not cover the case of passing a '/v2' module path to 'go get' when the module does not contain a package at its root. This CL is a minimal fix for that case, intended to be backportable to 1.13. (Longer term, I intend to rework the version-validation check to treat all mismatched paths as ErrNotExist.) Fixes #34746 Updates #34383 Change-Id: Ia963c2ea00fae424812b8f46a4d6c2c668252147 Reviewed-on: https://go-review.googlesource.com/c/go/+/199839 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Elias Naur authored
Fixes #32260 Change-Id: Ib44ee33b8143d523875cf5a2bc5e36bf082801a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/199918 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
You were a useful port and you've served your purpose. Thanks for all the play. A subsequent CL will remove amd64p32 (including assembly files and toolchain bits) and remaining bits. The amd64p32 removal will be separated into its own CL in case we want to support the Linux x32 ABI in the future and want our old amd64p32 support as a starting point. Updates #30439 Change-Id: Ia3a0c7d49804adc87bf52a4dea7e3d3007f2b1cd Reviewed-on: https://go-review.googlesource.com/c/go/+/199499 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
-
- 08 Oct, 2019 9 commits
-
-
Matthew Dempsky authored
n.Noescape() was overloaded for two uses: (1) to indicate a function was annotated with //go:noescape, and (2) to indicate that certain temporary allocations don't outlive the current statement. The first use case is redundant with n.Func.Pragma&Noescape!=0, which is the convention we use for checking other function-level pragmas. The second use case is better served by renaming "Noescape" to "Transient". Passes toolstash-check. Change-Id: I0f09d2d5767513894b7bf49da9cdabd04aa4a05e Reviewed-on: https://go-review.googlesource.com/c/go/+/199822 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
The newly introduced "late-stage" cycle detection for types (https://golang.org/cl/196338/) "skips" named types on the RHS of a type declaration when reporting a cycle. For instance, for: type ( A B B [10]C C A ) the reported cycle is: illegal cycle in declaration of C C refers to C because the underlying type of C resolves to [10]C (note that cmd/compile does the same but simply says invalid recursive type C). This CL introduces the Named.orig field which always refers to the RHS type in a type definition (and is never changed). By using Named.orig rather than Named.underlying for the type validity check, the cycle as written in the source code is reported: illegal cycle in declaration of A A refers to B refers to C refers to A Fixes #34771. Change-Id: I41e260ceb3f9a15da87ffae6a3921bd8280e2ac4 Reviewed-on: https://go-review.googlesource.com/c/go/+/199937 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Katie Hockman authored
Fixes #34702 Change-Id: I98320d54726e646a310e583283ddab676c3503e7 Reviewed-on: https://go-review.googlesource.com/c/go/+/199838 Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Dan Peterson authored
Fixes #27841 Change-Id: Ifcfd938aff8680cf7b44dfc09fde01d6105345a0 Reviewed-on: https://go-review.googlesource.com/c/go/+/198257 Run-TryBot: Dan Peterson <dpiddy@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Davor Kapsa authored
Change-Id: Icbf97d640fb26eed646f9e85c1f1c94b1469ca4f Reviewed-on: https://go-review.googlesource.com/c/go/+/199778Reviewed-by:
-
Robert Griesemer authored
Avoid confusion between (now gone) objSet and objset types. Also: rename visited -> seen in initorder.go. No functional changes. Change-Id: Ib0aa25e006eee55a79a739194d0d26190354a9f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/198044Reviewed-by:
-
Robert Griesemer authored
- remove Checker.cycle in favor of using a "seen" map - rename Checker.typeCycle -> Checker.cycle - remove TODO in api.go since the API is frozen Change-Id: I182a8215978dad54e9c6e79c21c5ec88ec802349 Reviewed-on: https://go-review.googlesource.com/c/go/+/198042Reviewed-by:
-
Robert Griesemer authored
For Go 1.13, we rewrote the go/types cycle detection scheme. Unfortunately, it was a bit too clever and introduced a bug (#34333). Here's an example: type A struct { f1 *B f2 B } type B A When type-checking this code, the first cycle A->*B->B->A (via field f1) is ok because there's a pointer indirection. Though in the process B is considered "type-checked" (and painted/marked from "grey" to black"). When type-checking f2, since B is already completely set up, go/types doesn't complain about the invalid cycle A->B->A (via field f2) anymore. On the other hand, with the fields f1, f2 swapped: type A struct { f2 B f1 *B } go/types reports an error because the cycle A->B->A is type-checked first. In general, we cannot know the "right" order in which types need to be type-checked. This CL fixes the issue as follows: 1) The global object path cycle detection does not take (pointer, function, reference type) indirections into account anymore for cycle detection. That mechanism was incorrect to start with and the primary cause for this issue. As a consequence we don't need Checker.indirectType and indir anymore. 2) After processing type declarations, Checker.validType is called to verify that a type doesn't expand indefinitively. This corresponds essentially to cmd/compile's dowidth computation (without size computation). 3) Cycles involving only defined types (e.g.: type (A B; B C; C A)) require separate attention as those must now be detected when resolving "forward chains" of type declarations. Checker.underlying was changed to detect these cycles. All three cycle detection mechanism use an object path ([]Object) to report cycles. The cycle error reporting mechanism is now factored out into Checker.cycleError and used by all three mechanisms. It also makes an attempt to report the cycle starting with the "first" (earliest in the source) object. Fixes #34333. Change-Id: I2c6446445e47344cc2cd034d3c74b1c345b8c1e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/196338 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Lynn Boger authored
This improves the code generated for LoweredMove and LoweredZero by using LXVD2X and STXVD2X to move 16 bytes at a time. These instructions are now used if the size to be moved or zeroed is >= 64. These same instructions have already been used in the asm implementations for memmove and memclr. Some examples where this shows an improvement on power8: MakeSlice/Byte 27.3ns ± 1% 25.2ns ± 0% -7.69% MakeSlice/Int16 40.2ns ± 0% 35.2ns ± 0% -12.39% MakeSlice/Int 94.9ns ± 1% 77.9ns ± 0% -17.92% MakeSlice/Ptr 129ns ± 1% 103ns ± 0% -20.16% MakeSlice/Struct/24 176ns ± 1% 131ns ± 0% -25.67% MakeSlice/Struct/32 200ns ± 1% 142ns ± 0% -29.09% MakeSlice/Struct/40 220ns ± 2% 156ns ± 0% -28.82% GrowSlice/Byte 81.4ns ± 0% 73.4ns ± 0% -9.88% GrowSlice/Int16 118ns ± 1% 98ns ± 0% -17.03% GrowSlice/Int 178ns ± 1% 134ns ± 1% -24.65% GrowSlice/Ptr 249ns ± 4% 212ns ± 0% -14.94% GrowSlice/Struct/24 294ns ± 5% 215ns ± 0% -27.08% GrowSlice/Struct/32 315ns ± 1% 248ns ± 0% -21.49% GrowSlice/Struct/40 382ns ± 4% 289ns ± 1% -24.38% ExtendSlice/IntSlice 109ns ± 1% 90ns ± 1% -17.51% ExtendSlice/PointerSlice 142ns ± 2% 118ns ± 0% -16.75% ExtendSlice/NoGrow 6.02ns ± 0% 5.88ns ± 0% -2.33% Append 27.2ns ± 0% 27.6ns ± 0% +1.38% AppendGrowByte 4.20ms ± 3% 2.60ms ± 0% -38.18% AppendGrowString 134ms ± 3% 102ms ± 2% -23.62% AppendSlice/1Bytes 5.65ns ± 0% 5.67ns ± 0% +0.35% AppendSlice/4Bytes 6.40ns ± 0% 6.55ns ± 0% +2.34% AppendSlice/7Bytes 8.74ns ± 0% 8.84ns ± 0% +1.14% AppendSlice/8Bytes 5.68ns ± 0% 5.70ns ± 0% +0.40% AppendSlice/15Bytes 9.31ns ± 0% 9.39ns ± 0% +0.86% AppendSlice/16Bytes 14.0ns ± 0% 5.8ns ± 0% -58.32% AppendSlice/32Bytes 5.72ns ± 0% 5.68ns ± 0% -0.66% AppendSliceLarge/1024Bytes 918ns ± 8% 615ns ± 1% -33.00% AppendSliceLarge/4096Bytes 3.25µs ± 1% 1.92µs ± 1% -40.84% AppendSliceLarge/16384Bytes 8.70µs ± 2% 4.69µs ± 0% -46.08% AppendSliceLarge/65536Bytes 18.1µs ± 3% 7.9µs ± 0% -56.30% AppendSliceLarge/262144Bytes 69.8µs ± 2% 25.9µs ± 0% -62.91% AppendSliceLarge/1048576Bytes 258µs ± 1% 93µs ± 0% -63.96% Change-Id: I21625dbe231a2029ddb9f7d73f5a6417b35c1e49 Reviewed-on: https://go-review.googlesource.com/c/go/+/199639 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
