- 29 May, 2019 5 commits
-
-
Matthew Dempsky authored
Change-Id: Idd3acf5f808705c608cd4e5877bc93e1626d9a58 Reviewed-on: https://go-review.googlesource.com/c/go/+/179238 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Matthew Dempsky authored
This CL rewrites cmd/compile's package-level initialization ordering algorithm to be compliant with the Go spec. See documentation in initorder.go for details. Incidentally, this CL also improves fidelity of initialization loop diagnostics by including referenced functions in the emitted output like go/types does. Fixes #22326. Change-Id: I7c9ac47ff563df4d4f700cf6195387a0f372cc7b Reviewed-on: https://go-review.googlesource.com/c/go/+/170062 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Jason A. Donenfeld authored
Incredibly, the subsystem version numbers in the PE header influence how win32k handles various syscalls. The first time a win32k syscall is invoked and the kernel upgrades the thread object to a tagTHREADINFO with all of the lovely undocumented UI members and such, it sets the dwExpWinVer member (offset 624 in Windows 10 build 1809) to the result of RtlGetExpWinVer(PsGetProcessSectionBaseAddress(proc)). RtlGetExpWinVer, also undocumented, then calls into the undocumented RtlImageNtHeader function, which returns a fortunately documented IMAGE_NT_HEADERS structure. It uses the subsystem members in there to set the dwExpWinVer member of our newly minted tagTHREADINFO object. Later, functions like SendInput consult this to vary their behaviors and return values. In fact, littered through out win32k are checks like `if (gsti->dwExpWinVer >= 0x501) { ... }`. I don't think Go ever supported NT 4.0. These days the minimum version is Windows 7, which is 6.1. So, let's set the version numbers in the PE header at that, which should give us the behavior that MSDN advertises for various functions, as opposed to bizarre archeological remnants. Interestingly, I suspect that most people never noticed the brokenness, because most people trying to do serious Win32 UI stuff wind up linking in cgo, if not for actually using C, then just to have a larger system stack so that the stack doesn't get corrupted by various UI functions. When MingW is used, the PE header gets a later version. But recently there's been a bug report of some people trying to do more modest UI manipulation using SendInput in a setting where this cgo hack probably isn't required, so they ran into the weird historical compatibility stuff. Fixes #31685 Change-Id: I54461ce820f6e9df349e37be5ecc5a44c04a3e26 Reviewed-on: https://go-review.googlesource.com/c/go/+/178977 Run-TryBot: Jason Donenfeld <Jason@zx2c4.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
The default is now "https://proxy.golang.org,direct" not just "https://proxy.golang.org" (as of CL 178720). Change-Id: I47e67602e994332b988ed1b75fa57319f3876cc6 Reviewed-on: https://go-review.googlesource.com/c/go/+/178725 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Keith Randall authored
Change-Id: I0f79d317ae7ac46c7e824bd382a4f51d53adaaa6 Reviewed-on: https://go-review.googlesource.com/c/go/+/179257 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
- 28 May, 2019 7 commits
-
-
Brad Fitzpatrick authored
Fixes #32102 Change-Id: I3022104035a12bf31a7cd214aede58c024effc1b Reviewed-on: https://go-review.googlesource.com/c/go/+/179180Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Brad Fitzpatrick authored
One of these tests creates a bunch of connections concurrently, then discovers it doesn't need them all, which then makes the server log that the client went away midway through the TLS handshake. Perhaps the server should recognize that as a case not worthy of logging about, but this is a safer way to eliminate the stderr spam during go test for now. The other test's client gives up on its connection and closes it, similarly confusing the server. Change-Id: I49ce442c9a63fc437e58ca79f044aa76e8c317b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/179179 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
Josh Bleecher Snyder authored
The code in #29218 resulted in an If block containing only its control. That block was then converted by fuseIf into a plain block; as a result, that control value was dead. However, the control value was still present in b.Values. This prevented further fusing of that block. This change beefs up the check in fuseIf to allow fusing blocks that contain only dead values (if any). In the case of #29218, this enables enough extra fusing that the control value could be eliminated, allowing all values in turn to be eliminated. This change also fuses 34 new blocks during make.bash. It is not clear that this fixes every variant of #29218, but it is a reasonable standalone change. And code like #29218 is rare and fundamentally buggy, so we can handle new instances if/when they actually occur. Fixes #29218 Negligible toolspeed impact. name old time/op new time/op delta Template 213ms ± 3% 213ms ± 2% ~ (p=0.914 n=97+88) Unicode 89.8ms ± 2% 89.6ms ± 2% -0.22% (p=0.045 n=93+95) GoTypes 712ms ± 3% 709ms ± 2% -0.35% (p=0.023 n=95+95) Compiler 3.24s ± 2% 3.23s ± 2% -0.30% (p=0.020 n=98+97) SSA 10.0s ± 1% 10.0s ± 1% ~ (p=0.382 n=98+99) Flate 135ms ± 3% 135ms ± 2% ~ (p=0.983 n=98+98) GoParser 158ms ± 2% 158ms ± 2% ~ (p=0.170 n=99+99) Reflect 447ms ± 3% 447ms ± 2% ~ (p=0.538 n=98+89) Tar 189ms ± 2% 189ms ± 3% ~ (p=0.874 n=95+96) XML 251ms ± 2% 251ms ± 2% ~ (p=0.434 n=94+96) [Geo mean] 427ms 426ms -0.15% name old user-time/op new user-time/op delta Template 264ms ± 2% 265ms ± 2% ~ (p=0.075 n=96+90) Unicode 119ms ± 6% 119ms ± 7% ~ (p=0.864 n=99+98) GoTypes 926ms ± 2% 924ms ± 2% ~ (p=0.071 n=94+94) Compiler 4.38s ± 2% 4.37s ± 2% -0.34% (p=0.001 n=98+97) SSA 13.4s ± 1% 13.4s ± 1% ~ (p=0.693 n=90+93) Flate 162ms ± 3% 161ms ± 2% ~ (p=0.163 n=99+99) GoParser 186ms ± 2% 186ms ± 3% ~ (p=0.130 n=96+100) Reflect 572ms ± 3% 572ms ± 2% ~ (p=0.608 n=97+97) Tar 239ms ± 2% 239ms ± 3% ~ (p=0.999 n=93+91) XML 302ms ± 2% 302ms ± 2% ~ (p=0.627 n=91+97) [Geo mean] 540ms 540ms -0.08% file before after Δ % asm 4862704 4858608 -4096 -0.084% compile 24001568 24001680 +112 +0.000% total 132520780 132516796 -3984 -0.003% file before after Δ % cmd/compile/internal/gc.a 8887638 8887596 -42 -0.000% cmd/compile/internal/ssa.a 29995056 29998986 +3930 +0.013% cmd/internal/obj/wasm.a 209444 203652 -5792 -2.765% total 129471798 129469894 -1904 -0.001% Change-Id: I2d18f9278e68b9766058ae8ca621e844f9d89dd8 Reviewed-on: https://go-review.googlesource.com/c/go/+/177140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
-
Dmitri Shuralyov authored
It was added in CL 83956 but never used. Updates #23129 Change-Id: I70b50e974a56620069a77658386722af314cc857 Reviewed-on: https://go-review.googlesource.com/c/go/+/179138 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Maxim Eryomenko authored
Change-Id: Iec4348eb674c8c64497c82e5d7cd656736cfcebd GitHub-Last-Rev: 462c323960be0ca1c126c051ab97f72949bdc2b6 GitHub-Pull-Request: golang/go#32225 Reviewed-on: https://go-review.googlesource.com/c/go/+/178797Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #32119 Change-Id: I8cf2e2e69737e2485568af91ab75149f3cf66781 Reviewed-on: https://go-review.googlesource.com/c/go/+/178918 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Rob Pike authored
There was an implicit heuristic before about when to print the package clause or omit it, but it was undocumented and confusing. Get rid of it and print it always unless asking for the package docs for a command, which are more of a usage message than a programming question. This simplifies the processing. There are several paths to the output, so to put the fix in one place we place a wrapper before the output buffer than adds the clause when Write is first called. The tests don't verify this behavior, but they didn't before either. Unsure what the right approach is but this will do for now. Fixes #31457 Change-Id: Ia6a9e740d556f45265c55f06b5306621c7a40ea9 Reviewed-on: https://go-review.googlesource.com/c/go/+/177797Reviewed-by: Russ Cox <rsc@golang.org>
-
- 27 May, 2019 1 commit
-
-
Ian Lance Taylor authored
These tests assume that it is OK to switch between time implementations, but the clock_gettime call uses CLOCK_MONOTONIC and the fallback call, gettimeofday, uses CLOCK_REALTIME. Disabling the clock_gettime call means that calls to nanotime will start returning very different values. This breaks the new timer code, which assumes that nanotime will return a consistently increasing value. This test is not very useful in any case as it doesn't check the results. Removing this file also removes BenchmarkTimeNow, which is a duplicate of BenchmarkNow in the time package. Updates #27707 Fixes #32109 Change-Id: I6a884af07f75822d724193c5eed94742f524f07d Reviewed-on: https://go-review.googlesource.com/c/go/+/174679Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 25 May, 2019 2 commits
-
-
Agniva De Sarker authored
Fixes #32044 Change-Id: Ia220dbbe4d6851befe28dd2d4b8a1a7bc2757460 Reviewed-on: https://go-review.googlesource.com/c/go/+/178878 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Than McIntosh authored
The constant defined in macho.go for LC_LOAD_WEAK_DYLIB was not correct, was 0x18 should have been 0x80000018. Switch to the correct definition. Fixes #32233. Change-Id: I9fb660a3cfd5e8c451a64947258f7ead76d98c79 Reviewed-on: https://go-review.googlesource.com/c/go/+/178723 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
-
- 24 May, 2019 10 commits
-
-
Russ Cox authored
Getenv("GOPROXY") says what the environment variable is (including looking in the go env file), but it doesn't include the default setting. This code needs to use cfg.GOPROXY to get the actual default. Fix and test that. Also, we forgot to include the fallback to direct for when the proxy serves a 404. Add and test that too. Also add HTTP fetch information to -x build flag output. (It does not belong in the -v output, despite the GOPATH go get command doing this.) Change-Id: Ieab7ef13cda3e1ad041dbe04921af206e2232c9c Reviewed-on: https://go-review.googlesource.com/c/go/+/178720 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Bryan C. Mills authored
Since we're mucking with error-propagation in modload.Query* anyway, simplify the classification logic. Ensure that “module not found” errors are reported as such in various places, since non-“not found” errors terminate the module search. Fixes #31785 Change-Id: Ie3ca5f4eec10a5f2a6037ec7e1c2cf47bd37a232 Reviewed-on: https://go-review.googlesource.com/c/go/+/177958 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Cherry Zhang authored
Following the previous CL, this removes more global variables on Wasm. PC_B is used mostly for intra-function jumps, and for a function telling its callee where to start or resume. This usage can be served by a parameter. The top level loop (wasm_pc_f_loop) uses PC_B for resuming a function. This value is either set by gogo, or loaded from the Go stack at function return. Instead of loading PC_B at each function return, we could make gogo stores PC_B at the same stack location, and let the top level loop do the load. This way, we don't need to use global PC_B to communicate with the top level loop, and we can replace global PC_B with a parameter. PC_F is similar. It is even more so in that the only reader is the top level loop. Let the top level loop read it from the stack, and we can get rid of PC_F entirely. PC_F and PC_B are used less entensively as SP, so this CL has smaller performance gain. Running on Chrome 74.0.3729.108 on Linux/AMD64, name old time/op new time/op delta BinaryTree17 16.6s ± 0% 16.2s ± 1% -2.59% (p=0.016 n=4+5) Fannkuch11 11.1s ± 1% 10.8s ± 0% -2.65% (p=0.008 n=5+5) FmtFprintfEmpty 231ns ± 1% 217ns ± 0% -6.06% (p=0.008 n=5+5) FmtFprintfString 407ns ± 3% 375ns ± 2% -7.81% (p=0.008 n=5+5) FmtFprintfInt 466ns ± 2% 430ns ± 0% -7.79% (p=0.016 n=5+4) FmtFprintfIntInt 719ns ± 2% 673ns ± 2% -6.37% (p=0.008 n=5+5) FmtFprintfPrefixedInt 706ns ± 1% 676ns ± 3% -4.31% (p=0.008 n=5+5) FmtFprintfFloat 1.01µs ± 1% 0.97µs ± 1% -4.30% (p=0.008 n=5+5) FmtManyArgs 2.67µs ± 1% 2.51µs ± 1% -5.95% (p=0.008 n=5+5) GobDecode 30.7ms ± 9% 31.3ms ±34% ~ (p=0.222 n=5+5) GobEncode 24.2ms ±23% 20.2ms ± 0% -16.36% (p=0.016 n=5+4) Gzip 852ms ± 0% 823ms ± 0% -3.38% (p=0.016 n=4+5) Gunzip 160ms ± 1% 151ms ± 1% -5.37% (p=0.008 n=5+5) JSONEncode 35.7ms ± 1% 34.3ms ± 1% -3.81% (p=0.008 n=5+5) JSONDecode 247ms ± 8% 254ms ± 7% ~ (p=0.548 n=5+5) Mandelbrot200 5.39ms ± 0% 5.41ms ± 0% +0.42% (p=0.008 n=5+5) GoParse 18.5ms ± 1% 18.3ms ± 2% ~ (p=0.343 n=4+4) RegexpMatchEasy0_32 424ns ± 2% 397ns ± 0% -6.23% (p=0.008 n=5+5) RegexpMatchEasy0_1K 2.88µs ± 0% 2.86µs ± 1% ~ (p=0.079 n=5+5) RegexpMatchEasy1_32 395ns ± 2% 370ns ± 1% -6.23% (p=0.008 n=5+5) RegexpMatchEasy1_1K 3.26µs ± 0% 3.19µs ± 1% -2.06% (p=0.008 n=5+5) RegexpMatchMedium_32 564ns ± 1% 532ns ± 0% -5.71% (p=0.008 n=5+5) RegexpMatchMedium_1K 146µs ± 2% 140µs ± 1% -4.62% (p=0.008 n=5+5) RegexpMatchHard_32 8.47µs ± 1% 7.91µs ± 1% -6.65% (p=0.008 n=5+5) RegexpMatchHard_1K 253µs ± 1% 236µs ± 2% -6.66% (p=0.008 n=5+5) Revcomp 1.78s ± 4% 1.76s ± 5% ~ (p=1.000 n=5+5) Template 292ms ±29% 269ms ± 5% ~ (p=0.690 n=5+5) TimeParse 1.61µs ± 4% 1.54µs ± 1% -4.42% (p=0.008 n=5+5) TimeFormat 1.66µs ± 3% 1.58µs ± 1% -5.22% (p=0.008 n=5+5) [Geo mean] 232µs 221µs -4.54% name old speed new speed delta GobDecode 25.0MB/s ± 8% 25.1MB/s ±27% ~ (p=0.222 n=5+5) GobEncode 32.8MB/s ±21% 38.0MB/s ± 0% +15.84% (p=0.016 n=5+4) Gzip 22.8MB/s ± 0% 23.6MB/s ± 0% +3.49% (p=0.016 n=4+5) Gunzip 121MB/s ± 1% 128MB/s ± 1% +5.68% (p=0.008 n=5+5) JSONEncode 54.4MB/s ± 1% 56.5MB/s ± 1% +3.97% (p=0.008 n=5+5) JSONDecode 7.88MB/s ± 8% 7.65MB/s ± 8% ~ (p=0.548 n=5+5) GoParse 3.07MB/s ± 8% 3.00MB/s ±22% ~ (p=0.579 n=5+5) RegexpMatchEasy0_32 75.6MB/s ± 2% 80.5MB/s ± 0% +6.58% (p=0.008 n=5+5) RegexpMatchEasy0_1K 356MB/s ± 0% 358MB/s ± 1% ~ (p=0.095 n=5+5) RegexpMatchEasy1_32 81.1MB/s ± 2% 86.5MB/s ± 1% +6.69% (p=0.008 n=5+5) RegexpMatchEasy1_1K 314MB/s ± 0% 320MB/s ± 0% +2.10% (p=0.008 n=5+5) RegexpMatchMedium_32 1.77MB/s ± 1% 1.88MB/s ± 0% +6.09% (p=0.016 n=5+4) RegexpMatchMedium_1K 6.99MB/s ± 2% 7.33MB/s ± 1% +4.83% (p=0.008 n=5+5) RegexpMatchHard_32 3.78MB/s ± 1% 4.04MB/s ± 1% +7.04% (p=0.008 n=5+5) RegexpMatchHard_1K 4.04MB/s ± 1% 4.33MB/s ± 2% +7.17% (p=0.008 n=5+5) Revcomp 143MB/s ± 4% 145MB/s ± 5% ~ (p=1.000 n=5+5) Template 6.77MB/s ±24% 7.22MB/s ± 5% ~ (p=0.690 n=5+5) [Geo mean] 24.4MB/s 25.4MB/s +4.18% Change-Id: Ib80716e62992aec28b2c4a96af280c278f83aa49 Reviewed-on: https://go-review.googlesource.com/c/go/+/173980 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Richard Musiol <neelance@gmail.com>
-
Michael Anthony Knyszek authored
Currently there's an invariant in the runtime wherein the heap lock can only be acquired on the system stack, otherwise a self-deadlock could occur if the stack grows while the lock is held. This invariant is upheld and documented in a number of situations (e.g. allocManual, freeManual) but there are other places where the invariant is either not maintained at all which risks self-deadlock (e.g. setGCPercent, gcResetMarkState, allocmcache) or is maintained but undocumented (e.g. gcSweep, readGCStats_m). This change adds go:systemstack to any function that acquires the heap lock or adds a systemstack(func() { ... }) around the critical section, where appropriate. It also documents the invariant on (*mheap).lock directly and updates repetitive documentation to refer to that comment. Fixes #32105. Change-Id: I702b1290709c118b837389c78efde25c51a2cafb Reviewed-on: https://go-review.googlesource.com/c/go/+/177857 Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Austin Clements <austin@google.com>
-
Martin Sucha authored
I have seen code that literally copied the example like this: if strings.ContainsAny(s, "1 & 2 & 3") { The developer apparently thought that this is the way to specify multiple characters and I noticed this pattern being used in the example. Let's update the example so that it's clear how multiple Unicode code points should be specified. Change-Id: Id4d780555e521af62fb787a7950be1e60848cd95 Reviewed-on: https://go-review.googlesource.com/c/go/+/178737Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Leon Klingele authored
Change-Id: Ic5b01c0a6912d87e812331d6525939df8f525cca GitHub-Last-Rev: b6ffefcf8f2ec1ed7ee13f36e8fef6af965ba332 GitHub-Pull-Request: golang/go#29993 Reviewed-on: https://go-review.googlesource.com/c/go/+/160417Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Hana (Hyang-Ah) Kim authored
Change-Id: If001d8f7e657e01711653827a170904932839e34 Reviewed-on: https://go-review.googlesource.com/c/go/+/178721 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Leon Klingele authored
Change-Id: Ib7be503a46f3609ea29464569e57e1f620e97a53 GitHub-Last-Rev: a43cffe45f3b9d208028f7682088cbe537d6deca GitHub-Pull-Request: golang/go#30007 Reviewed-on: https://go-review.googlesource.com/c/go/+/160431 Run-TryBot: Leon Klingele <git@leonklingele.de> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Richard Musiol authored
The typed arrays returned by TypedArrayOf were backed by WebAssembly memory. They became invalid each time we grow the WebAssembly memory. This made them very error prone and hard to use correctly. This change removes TypedArrayOf completely and instead introduces CopyBytesToGo and CopyBytesToJS for copying bytes between a byte slice and an Uint8Array. This breaking change is still allowed for the syscall/js package. Fixes #31980. Fixes #31812. Change-Id: I14c76fdd60b48dd517c1593972a56d04965cb272 Reviewed-on: https://go-review.googlesource.com/c/go/+/177537 Run-TryBot: Richard Musiol <neelance@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
bill_ofarrell authored
Utilize KDSA when available. This guarantees constant time operation on all three curves mentioned, and is faster than conventional assembly. The IBM Z model(s) that support KDSA as used in this CL are not yet publicly available, and so we are unable to release performance data at this time. Change-Id: I85360dcf90fe42d2bf32afe3f638e282de10a518 Reviewed-on: https://go-review.googlesource.com/c/go/+/174437 Run-TryBot: Michael Munday <mike.munday@ibm.com> Reviewed-by: Michael Munday <mike.munday@ibm.com>
-
- 23 May, 2019 13 commits
-
-
Brad Fitzpatrick authored
This is now recognized and recommended by GitHub. Fixes #32201 Change-Id: Iafb5ef1b2bee5f021a711b0b758aaf6a74758c5d Reviewed-on: https://go-review.googlesource.com/c/go/+/178697Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
This test was designed for #15609 and didn't consider nacl. It's not worth adding new +build-guarded assembly files in issue15609.dir for nacl, especially as nacl is going away. Fixes #32206 Change-Id: Ic5bd48b4f790a1f7019100b8a72d4688df75512f Reviewed-on: https://go-review.googlesource.com/c/go/+/178698 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Michael McLoughlin authored
Replaces putUint{32,64} functions in crypto/sha* packages with the equivalent functions encoding/binary.BigEndian.PutUint{32,64}. Change-Id: I9208d2125202ea9c97777560e6917d21893aced0 Reviewed-on: https://go-review.googlesource.com/c/go/+/156117Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Leon Klingele authored
Change-Id: Ia42a4a658e4207cc1f036f2faeac011e71edad77 GitHub-Last-Rev: b384f81799fcd404f53647d8a3015487ea240c6f GitHub-Pull-Request: golang/go#30012 Reviewed-on: https://go-review.googlesource.com/c/go/+/160436 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
andrius4669 authored
Encodes non-WSP CTL and non-US-ASCII UTF-8 characters using syntax specified in RFC 2231. Fixes #7668 Fixes #9624 Change-Id: I433f167c5bdd84a7f811ac0410b08b10790e0d9f GitHub-Last-Rev: 9c77146760341fdb3af35c1b94d4ee00ffb0daae GitHub-Pull-Request: golang/go#29328 Reviewed-on: https://go-review.googlesource.com/c/go/+/154760Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Caleb Spare authored
Float formatting uses a multiprecision fallback path where Grisu3 algorithm fails. This has a bug during the rounding phase: the difference between the decimal value and the upper bound is examined byte-by-byte and doesn't properly handle the case where the first divergence has a difference of 1. For instance (using an example from #29491), for the number 498484681984085570, roundShortest examines the three decimal values: lower: 498484681984085536 d: 498484681984085568 upper: 498484681984085600 After examining the 16th digit, we know that rounding d up will fall within the bounds unless all remaining digits of d are 9 and all remaining digits of upper are 0: d: ...855xx upper: ...856xx However, the loop forgets that d and upper have already diverged and then on the next iteration sees that the 17th digit of d is actually lower than the 17th digit of upper and decides that we still can't round up: d: ...8556x upper: ...8560x Thus the original value is incorrectly rounded down to 498484681984085560 instead of the closer (and equally short) 498484681984085570. Thanks to Brian Kessler for diagnosing this bug. Fix it by remembering when we've seen divergence in previous digits. This CL also fixes another bug in the same loop: for some inputs, the decimal value d or the lower bound may have fewer digits than the upper bound, yet the iteration through the digits starts at i=0 for each of them. For instance, given the float64 value 1e23, we have d: 99999999999999991611392 upper: 100000000000000000000000 but the loop starts by comparing '9' to '1' rather than '0' to '1'. I haven't found any cases where this second bug causes incorrect output because when the digit comparison fails on the first loop iteration the upper bound always has more nonzero digits (i.e., the expression 'i+1 < upper.nd' is always true). Fixes #29491 Change-Id: I58856a7a2e47935ec2f233d9f717ef15c78bb2d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/157697 Run-TryBot: Caleb Spare <cespare@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rémy Oudompheng <remyoudompheng@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
https://proxy.golang.orgRuss Cox authored
This CL changes the default module download and module verification mechanisms to use the Go module mirror and Go checksum database run by Google. See https://proxy.golang.org/privacy for the services' privacy policy. (Today, that URL is a redirect to Google's standard privacy policy, which covers these services as well. If we publish a more specific privacy policy just for these services, that URL will be updated to display or redirect to it.) See 'go help modules' and 'go help modules-auth' for details (added in this CL). To disable the mirror and checksum database for non-public modules: go env -w GONOPROXY=*.private.net,your.com/* go env -w GONOSUMDB=*.private.net,your.com/* (If you are using a private module proxy then you'd only do the second.) If you run into problems with the behavior of the go command when using the Go module mirror or the Go checksum database, please file issues at https://golang.org/issue/new, so that we can address them for the Go 1.13 release. For #25530. This CL also documents GONOPROXY. Fixes #32056. Change-Id: I2fde82e071742272b0842efd9580df1a56947fec Reviewed-on: https://go-review.googlesource.com/c/go/+/178179 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Mickey Reiss authored
Apologies for the the nitpicky PR. I believe there is a minor typo in the documentation of `MaxScanTokenSize`, which confused me for a moment when I went to search for the referenced method, `Scan.Buffer`. Thanks! Change-Id: I5d21e77276285206497fe75291001032c255cace GitHub-Last-Rev: 635e35c0191c11f2b6966b5e58cf91a1064099da GitHub-Pull-Request: golang/go#32193 Reviewed-on: https://go-review.googlesource.com/c/go/+/178637Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Agniva De Sarker authored
Fixes #31961 Change-Id: I9db9ecfd2f8ca7cf51df4413a6e0d66de5da7043 Reviewed-on: https://go-review.googlesource.com/c/go/+/178457 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Ariel Mashraki authored
The new slice function returns the result of slicing its first argument by the following arguments. Thus {{slice x 1 3}} is, in Go syntax, x[1:3]. Each sliced item must be a string, slice, or array. Closed #30153 RELNOTE=yes Change-Id: I63188c422848cee3d383a64dc4d046e3a1767c63 Reviewed-on: https://go-review.googlesource.com/c/go/+/161762Reviewed-by: Rob Pike <r@golang.org>
-
Martin Möhrmann authored
Like panicking and erroring - wrapErrs should always be reset to the default false. wrapErrs should only be true when set by Errorf. Change-Id: I4d51cc2f0905109e232b0983dc5331bd34f138bc Reviewed-on: https://go-review.googlesource.com/c/go/+/178517 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
-
LE Manh Cuong authored
Currently, some tests under test/fixedbugs never run: $ for d in test/fixedbugs/*.dir; do ! test -f "${d%.dir}.go" && echo "$d" done test/fixedbugs/issue15071.dir test/fixedbugs/issue15609.dir test/fixedbugs/issue29612.dir Because they missed the corresponding ".go" file, so "go run run.go" will skip them. Add missing ".go" files for those tests to make sure they will be collected and run. While at it, add another action "runindir", which does "go run ." inside the t.goDirName then check the output. Change-Id: I88000b3663a6a615d90c1cf11844ea0377403e3d Reviewed-on: https://go-review.googlesource.com/c/go/+/177798 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
We want the builders to be able to cross-compile test binaries for a few of the super slow builders that require either slow hardware or slow full CPU emulation. Updates golang/go#31217 Change-Id: I8d33b18efaf788f6f131354b2917ac9738ca975e Reviewed-on: https://go-review.googlesource.com/c/go/+/178399 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 22 May, 2019 2 commits
-
-
Leon Klingele authored
Change-Id: I8827cef0f57459384329c50c51795350da0ede4b GitHub-Last-Rev: c9ad9e12b5a0fff47c21a8c299b762b64b8c9c7c GitHub-Pull-Request: golang/go#30010 Reviewed-on: https://go-review.googlesource.com/c/go/+/160434 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
kawakami authored
This keeps transparency of a wrapped image.Image even after it is encoded. Fixes #30995 Change-Id: I1f7ac98b1741f83ed740f6eda6c36b7e9b16e5af Reviewed-on: https://go-review.googlesource.com/c/go/+/177377Reviewed-by: Hayato Kawakami <kawakami.ozone@gmail.com> Reviewed-by: Benny Siegert <bsiegert@gmail.com> Run-TryBot: Benny Siegert <bsiegert@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-