- 09 May, 2019 22 commits
-
-
Russ Cox authored
Working toward making the tree vet-safe instead of having so many exceptions in cmd/vet/all/whitelist. This CL makes "go vet -unsafeptr=false runtime" happy for these GOOS/GOARCHes, while keeping "GO_BUILDER_NAME=misc-vetall go tool dist test" happy too. For #31916. Change-Id: Ic64f7f4034695dd4c32c9b7f258960faf3742a83 Reviewed-on: https://go-review.googlesource.com/c/go/+/176103 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Working toward making the tree vet-safe instead of having so many exceptions in cmd/vet/all/whitelist. This CL makes "go vet -unsafeptr=false runtime" happy for these GOOS/GOARCHes, except for an unresolved complaint on mips/mipsle that is a bug in vet, while keeping "GO_BUILDER_NAME=misc-vetall go tool dist test" happy too. For #31916. Change-Id: I6ef7e982a2fdbbfbc22cee876ca37ac54d8109e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/176102 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Russ Cox authored
Working toward making the tree vet-safe instead of having so many exceptions in cmd/vet/all/whitelist. This CL makes "GOOS=linux GOARCH=arm go vet -unsafeptr=false runtime" happy, while keeping "GO_BUILDER_NAME=misc-vetall go tool dist test" happy too. For #31916. Change-Id: Ifae75b832320b5356ac8773cf85055bfb2bd7214 Reviewed-on: https://go-review.googlesource.com/c/go/+/176101 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Working toward making the tree vet-safe instead of having so many exceptions in cmd/vet/all/whitelist. This CL makes "GOOS=linux GOARCH=amd64 go vet -unsafeptr=false runtime" happy, while keeping "GO_BUILDER_NAME=misc-vetall go tool dist test" happy too. For #31916. Change-Id: I4ca1acb02f4666b102d25fcc55fac96b8f80379a Reviewed-on: https://go-review.googlesource.com/c/go/+/176100 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Russ Cox authored
Working toward making the tree vet-safe instead of having so many exceptions in cmd/vet/all/whitelist. This CL makes "GOOS=linux GOARCH=386 go vet -unsafeptr=false runtime" happy, while keeping "GO_BUILDER_NAME=misc-vetall go tool dist test" happy too. For #31916. Change-Id: I3e5586a7ff6e359357350d0602c2259493280ded Reviewed-on: https://go-review.googlesource.com/c/go/+/176099 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Michael Anthony Knyszek authored
Trybots started failing on js/wasm after golang.org/cl/175797 landed, but it seemed completely unrelated. It would fail very consistently on the heapsampling.go test. Digging deeper it was very difficult to ascertain what was going wrong, but clearly m.locks for some m was non-zero when calling into the scheduler. The failure comes from the fact that lock calls into gosched, but it's unclear how exactly we got there in the first place; there should be no preemption in this single-threaded context. Furthermore, lock shouldn't be calling gosched_m at all because in a single-threaded context, the thread shouldn't be preempted until it actually unlocks. But, digging further it turns out the implementation in lock_js.go never incremented or decremented m.locks. This is definitely wrong because many parts of the runtime depend on that value being set correctly. So, this change removes the loop which calls into gosched_m (which should be unnecessary) and increments and decrements m.locks appropriately. This appears to fix the aforementioned failure. Change-Id: Id214c0762c3fb2b405ff55543d7e2a78c17443c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/176297 Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
These ridiculous tags are testing what happens with very long tags. There is no need for them to be malformed as well. Fix them to make vet happier. Working toward making the tree vet-safe instead of having so many exceptions in cmd/vet/all/whitelist. For #31916. Change-Id: I100aed5230fcde41676c79c7074c69c16ea4b96d Reviewed-on: https://go-review.googlesource.com/c/go/+/176111 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Renaming the method makes clear, both to readers and to vet, that this method is not the implementation of io.ByteWriter. Working toward making the tree vet-safe instead of having so many exceptions in cmd/vet/all/whitelist. For #31916. Change-Id: I5b509eb7f0118d5f2d3c6e352ff2849cd5a3071e Reviewed-on: https://go-review.googlesource.com/c/go/+/176110 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Renaming the method makes clear, both to readers and to vet, that this method is not the implementation of io.ByteWriter. Working toward making the tree vet-safe instead of having so many exceptions in cmd/vet/all/whitelist. For #31916. Change-Id: I79da062ca6469b62a6b9e284c6cf2413c7425249 Reviewed-on: https://go-review.googlesource.com/c/go/+/176109 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Jay Conrod authored
Added documentation that explains special cases for vendored packages in the standard library and provides instructions for updating vendor directories. Fixes #31806 Change-Id: Ib697ed18eae28023ab0bfb9f4d250992c393571d Reviewed-on: https://go-review.googlesource.com/c/go/+/174999Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
Renaming the method makes clear, both to readers and to vet, that this method is not the implementation of io.Seeker: it cannot fail. Working toward making the tree vet-safe instead of having so many exceptions in cmd/vet/all/whitelist. For #31916. Change-Id: I3e6ad7264cb0121b4b76935450cccb71d533e96b Reviewed-on: https://go-review.googlesource.com/c/go/+/176108 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Anthony Knyszek authored
This change makes it so that during scavenging we split spans when the span we have next for scavenging is larger than the amount of work we have left to do. The purpose of this change is to improve the worst-case behavior of the scavenger: currently, if the scavenger only has a little bit of work to do but sees a very large free span, it will scavenge the whole thing, spending a lot of time to get way ahead of the scavenge pacing for no reason. With this change the scavenger should follow the pacing more closely, but may still over-scavenge by up to a physical huge page since the splitting behavior avoids breaking up huge pages in free spans. This change is also the culmination of the scavenging improvements, so we also include benchmark results for this series (starting from "runtime: merge all treaps into one implementation" until this patch). This patch stack results in average and peak RSS reductions (up to 11% and 7% respectively) for some benchmarks, with mostly minimal performance degredation (3-4% for some benchmarks, ~0% geomean). Each of these benchmarks was executed with GODEBUG=madvdontneed=1 on Linux; the performance degredation is even smaller when MADV_FREE may be used, but the impact on RSS is much harder to measure. Applications that generally maintain a steady heap size for the most part show no change in application performance. These benchmarks are taken from an experimental benchmarking suite representing a variety of open-source Go packages, the raw results may be found here: https://perf.golang.org/search?q=upload:20190509.1 For #30333. Change-Id: I618a48534d2d6ce5f656bb66825e3c383ab1ffba Reviewed-on: https://go-review.googlesource.com/c/go/+/175797 Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Austin Clements <austin@google.com>
-
Michael Anthony Knyszek authored
This change adds a background scavenging goroutine whose pacing is determined when the heap goal changes. The scavenger is paced to use at most 1% of the mutator's time for most systems. Furthermore, the scavenger's pacing is computed based on the estimated number of scavengable huge pages to take advantage of optimizations provided by the OS. The purpose of this scavenger is to deal with a shrinking heap: if the heap goal is falling over time, the scavenger should kick in and start returning free pages from the heap to the OS. Also, now that we have a pacing system, the credit system used by scavengeLocked has become redundant. Replace it with a mechanism which only scavenges on the allocation path if it makes sense to do so with respect to the new pacing system. Fixes #30333. Change-Id: I6203f8dc84affb26c3ab04528889dd9663530edc Reviewed-on: https://go-review.googlesource.com/c/go/+/142960 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Michael Anthony Knyszek authored
This change removes the periodic scavenger which goes over every span in the heap and scavenges it if it hasn't been used for 5 minutes. It should no longer be necessary if we have background scavenging (follow-up). For #30333. Change-Id: Ic3a1a4e85409dc25719ba4593a3b60273a4c71e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/143157 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Russ Cox authored
Fixes build - I did not understand that vetall was effectively pinned to a vet version by cmd/go.mod. Change-Id: I56bfd8f62eadacc97cad0ed48e41a178bbc18b8f Reviewed-on: https://go-review.googlesource.com/c/go/+/176179 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Than McIntosh authored
When targeting iOS, change the format (DWARF "form") of the call line attribute for inlined subroutine DIEs, to work around an apparent bug in /usr/bin/symbols on Darwin. [Just for posterity: there is nothing wrong with using DW_FORM_udata for the call_line attribute form; this is perfectly legal DWARF (and is in fact recommended by the standard relative to data4, which is less descriptive and often takes more space). The form switch is there just to make the Apple tools happy.] Updates #31459. Change-Id: Iaf362788a8c6684eea4cde8956c0661b694cecc1 Reviewed-on: https://go-review.googlesource.com/c/go/+/174538 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Russ Cox authored
The vetall builder runs vet straight out of golang.org/x/tools, so submiting CL 176097 in that repo will break the builder by making all these whitelist entries stale. Submiting this CL will fix it, by removing them. The addition of the gcWriteBarrier declaration in runtime/stubs.go is necessary because the diagnostic is no longer emitted on arm, so it must be removed from all.txt. Adding it to runtime is better than adding it to every-other-goarch.txt. For #31916. Change-Id: I432f6049cd3ee5a467add5066c440be8616d9d54 Reviewed-on: https://go-review.googlesource.com/c/go/+/176177 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
David Chase authored
This seems to deflake the test, and also allows testing on macOS. Fixes #31786. Change-Id: I10bfba46dd4b8e64cb09fdd4dd9d175c1ce1f022 Reviewed-on: https://go-review.googlesource.com/c/go/+/176058 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Than McIntosh authored
In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Elias Naur authored
Fixes #31917 Change-Id: I794e457b2245d355e2df5077078c67aa09e00ff9 Reviewed-on: https://go-review.googlesource.com/c/go/+/175920 Run-TryBot: Elias Naur <mail@eliasnaur.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
f+0(SB) is a non-standard but acceptable alias for f(SB). Fixes #30968. Change-Id: I499ccee4d3ff3ab4e47f75d99407aace858e59aa Reviewed-on: https://go-review.googlesource.com/c/go/+/174537Reviewed-by: Austin Clements <austin@google.com>
-
Russ Cox authored
The most common failure mode of the current std/cmd setup is going to be people running "go get m@latest" and then not running "go mod vendor" and being confused about getting the old m. Diagnose and report what to do. Also, having done the check, when in the standard library, switch the go command to -mod=vendor mode. This avoids some network accesses I saw when running 'go clean -modcache' before doing some work in cmd. Change-Id: I0ba4a66637b67225a9b97a1c89f26f9015b41673 Reviewed-on: https://go-review.googlesource.com/c/go/+/174528 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
- 08 May, 2019 16 commits
-
-
Brad Fitzpatrick authored
And use it in two internal windows packages, so they don't show up in "go list std" or binary releases on non-Windows platforms. Fixes #31920 Change-Id: Iaa292b6015c9d7310dd677c9e296006440ba5e27 Reviewed-on: https://go-review.googlesource.com/c/go/+/175983Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
noteRule is useful when you're trying to debug a particular rule, or get a general sense for how often a rule fires overall. It is less useful if you're trying to figure out which functions might be useful to benchmark to ascertain the impact of a newly added rule. Enter countRule. You use it like noteRule, except that you get per-function summaries. Sample output: # runtime (*mspan).sweep: idx1=1 evacuate_faststr: idx1=1 evacuate_fast32: idx1=1 evacuate: idx1=2 evacuate_fast64: idx1=1 sweepone: idx1=1 purgecachedstats: idx1=1 mProf_Free: idx1=1 This suggests that the map benchmarks might be good to run for this added rule. Change-Id: Id471c3231f1736165f2020f6979ff01c29677808 Reviewed-on: https://go-review.googlesource.com/c/go/+/167088 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Brad Fitzpatrick authored
Updates #31920 Change-Id: Ie24ed5bab249e2f90d1740f42a8b8d94fd0983f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/176019Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
Austin Clements authored
compilebench depends on the legacy heap profile format to read the allocation stats of build tools. We're adding a benchmark for the linker to compilebench, so we need the linker to emit the heap profile in the legacy format. This is the linker equivalent of CL 35484, which did this for the compiler. Change-Id: I16ad60c4f0fd80b4b6d608a5677ebe04e1fb5e5a Reviewed-on: https://go-review.googlesource.com/c/go/+/176057 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Marwan Sulaiman authored
When running go build with the flag -mod=readonly, it fails the build if go.sum files requires updating. This ensures that CI/CD systems get a complete go.sum file so that they'd never hit a notary, assuming the CI/CD system passes the above flag. I am not familiar with the entire codebase but I assume goSum.dirty will always be true if go.sum has any missing lines. Fixes #30667 Change-Id: I767d3b594055d8c10048f4c68e6687c94bb0545c Reviewed-on: https://go-review.googlesource.com/c/go/+/166237Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alan Donovan authored
In IDE-like applications (and also in tests), there is often a need to type-check an expression as if it appeared at a particular position in the source code of an already typed-checked package. Eval was added to address this need, but did so only partially, stopping short of exposing a type-annotated expression tree. This makes it impossible to resolve an expression such as new(T).x and discover what Object x refers to. CheckExpr exposes that generality. Eval is now implemented in terms of CheckExpr. This change includes a test that demonstrates the object resolution functionality just described. Historical context: - https://go-review.googlesource.com/c/tools/+/10800 - https://codereview.appspot.com/10748044/ Change-Id: I715ba934b9fc0c9ceb61270e20c5f91f4eff20c3 Reviewed-on: https://go-review.googlesource.com/c/go/+/144677 Run-TryBot: Alan Donovan <adonovan@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
JT Olio authored
benchmark old ns/op new ns/op delta BenchmarkRatCmp-4 154 77.9 -49.42% Change-Id: I932710ad8b6905879e232168b1777927f86ba22a Reviewed-on: https://go-review.googlesource.com/c/go/+/175460 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Dmitry Vyukov authored
Currently we say that a negative index means no match, but we don't say how "no match" is expressed when 'Index' is not present. Say how it is expressed. Change-Id: I82b6c9038557ac49852ac03642afc0bc545bb4a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/175677Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Change-Id: I2f2a70dd9279ab95fdabee51579d49363a9f65b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/176018 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Lorenz Nickel authored
Change-Id: I8563a20a4ba43cee7d4b73377c405a6ff12636e5 GitHub-Last-Rev: 0dae408845c7cf42667a65fff6f7d1a382e2d320 GitHub-Pull-Request: golang/go#31914 Reviewed-on: https://go-review.googlesource.com/c/go/+/176017Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Elias Naur authored
Satisfies the Apple Notary. Fixes #30488 Change-Id: I91cf2d706a3ebe79bafdb759a0d32266ed6b9096 Reviewed-on: https://go-review.googlesource.com/c/go/+/175918 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Russ Cox authored
The compiler output shown in the doc is now quite old (most of the changes happened in Go 1.5). Update it to be more like what users will actually see. Also explain how to get literal machine code again. Prompted by #30968. Change-Id: I0ce139c3fe299ccc43e85b6aca81c6e0aac1a2df Reviewed-on: https://go-review.googlesource.com/c/go/+/175757 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Elias Naur authored
Noticed while working on issue 30488. Change-Id: Ia3655e07c939d03925b3560eeba24c60e24c136c Reviewed-on: https://go-review.googlesource.com/c/go/+/175917 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
Gccgo's implementation of direct interface types has bugs that causes reflect Call of method from Type.Method fail. CL 175837 and CL 175798 fix the bug. This CL adds a test. Change-Id: I4e5f2cb96304c1ac7be04ca6d2851bac52b8eb24 Reviewed-on: https://go-review.googlesource.com/c/go/+/175880 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Stephan Zuercher authored
The PNG decode path attempts to handle paletted images that refer to non-existent palette indicies. This PR fixes a corner case were images that have exactly 255 palette colors and an IDAT chunk that references palette index 255 produce an invalid image such that invoking At on the pixel(s) in question causes an index out of range panic. Fixes #31830 Change-Id: I34c44d9de5b9d76fe8c45c04e866fbc7f51f2a9c Reviewed-on: https://go-review.googlesource.com/c/go/+/175397 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Nigel Tao <nigeltao@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
erifan01 authored
For the case where the addresses of parameter z and x of the function shlVU overlap and the address of z is greater than x, x (input value) can be polluted during the calculation when the high words of x are overlapped with the low words of z (output value). Fixes #31084 Change-Id: I9bb0266a1d7856b8faa9a9b1975d6f57dece0479 Reviewed-on: https://go-review.googlesource.com/c/go/+/169780 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
- 07 May, 2019 2 commits
-
-
Robert Griesemer authored
This change is a simple work-around to avoid a compiler crash and provide a reasonable error message. A future change should fix the root cause for this problem. Fixes #23823. Change-Id: Ifc80d9f4d35e063c378e54d5cd8d1cf4c0d2ec6a Reviewed-on: https://go-review.googlesource.com/c/go/+/175518Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Josh Bleecher Snyder authored
Change-Id: I4a70f4a52f84cf50f99939351319504b1c5dff76 Reviewed-on: https://go-review.googlesource.com/c/go/+/175777 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-