- 13 Oct, 2017 6 commits
-
-
Wei Xiao authored
Some ARM64-specific instructions (such as SIMD instructions) are not supported. This patch adds support for the following: 1. Extended register, e.g.: ADD Rm.<ext>[<<amount], Rn, Rd <ext> can have the following values: UXTB, UXTH, UXTW, UXTX, SXTB, SXTH, SXTW and SXTX 2. Arrangement for SIMD instructions, e.g.: VADDP Vm.<T>, Vn.<T>, Vd.<T> <T> can have the following values: B8, B16, H4, H8, S2, S4 and D2 3. Width specifier and element index for SIMD instructions, e.g.: VMOV Vn.<T>[index], Rd // MOV(to general register) <T> can have the following values: S and D 4. Register List, e.g.: VLD1 (Rn), [Vt1.<T>, Vt2.<T>, Vt3.<T>] 5. Register offset variant, e.g.: VLD1.P (Rn)(Rm), [Vt1.<T>, Vt2.<T>] // Rm is the post-index register 6. Go assembly for ARM64 reference manual new added instructions are required to have according explanation items in the manual and items for existed instructions will be added incrementally For more information about the refinement background, please refer to the discussion (https://groups.google.com/forum/#!topic/golang-dev/rWgDxCrL4GU) This patch only adds syntax and doesn't break any assembly that already exists. Change-Id: I34e90b7faae032820593a0e417022c354a882008 Reviewed-on: https://go-review.googlesource.com/41654 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by:Cherry Zhang <cherryyz@google.com>
-
Jed Denlea authored
The GIF format allows for an image to contain a global color table which might be used for some or every frame in an animated GIF. This palette contains 24-bit opaque RGB values. An individual frame may use the global palette and enable transparency by picking one number to be transparent, instead of the color value in the palette. image/gif decodes a GIF, which contains an []*image.Paletted that holds each frame. When decoded, if a frame has a transparent color and uses the global palette, a copy of the global []color.Color is made, and the transparency color index is replaced with color.RGBA{}. When encoding a GIF, each frame's palette is encoded to the form it might exist in a GIF, up to 768 bytes "RGBRGBRGBRGB...". If a frame's encoded palette is equal to the encoded global color table, the frame will be encoded with the flag set to use the global color table, otherwise the frame's palette will be included. So, if the color in the global color table that matches the transparent index of one frame wasn't black (and it frequently is not), reencoding a GIF will likely result in a larger file because each frame's palette will have to be encoded inline. This commit takes a frame's transparent color index into account when comparing an individual image.Paletted's encoded color table to the global color table. Fixes #22137 Change-Id: I5460021da6e4d7ce19198d5f94a8ce714815bc08 Reviewed-on: https://go-review.googlesource.com/68313Reviewed-by:Nigel Tao <nigeltao@golang.org>
-
David Chase authored
Excluded when -short because it still runs relatively long, but deflaked. Removed timeouts from normal path and ensured that they were not needed and that reference files did not change. Use "tbreak" instead of "break" with gdb to reduce chance of multiple hits on main.main. (Seems not enough, but a move in the right direction). By default, testing ignores repeated lines that occur when nexting. This appears to sometimes be timing-dependent and is the observed source of flakiness in testing so far. Note that these can also be signs of a bug in the generated debugging output, but it is one of the less-confusing bugs that can occur. By default, testing with gdb uses compilation with inlining disabled to prevent dependence on library code (it's a bug that library code is seen while Nexting, but the bug is current behavior). Also by default exclude all source files outside /testdata to prevent accidental dependence on library code. Note that this is currently only applicable to dlv because (for the debugging information we produce) gdb does not indicate a change in the source file for inlined code. Added flags -i and -r to make gdb testing compile with inlining and be sensitive to repeats in the next stream. This is for developer-testing and so we can describe these problems in bug reports. Updates #22206. Change-Id: I9a30ebbc65aa0153fe77b1858cf19743bdc985e4 Reviewed-on: https://go-review.googlesource.com/69930 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Tim Cooper authored
This somewhat mirrors the special case behavior of the copy built-in. Fixes #22215 Change-Id: Ic353003ad3de659d3a6b4e9d97295b42510f3bf7 Reviewed-on: https://go-review.googlesource.com/70431Reviewed-by:
-
Frank Somers authored
This is a preparation step for adding vDSO support on linux/386. This change relocates the elf64 and amd64 specifics from vdso_linux.go to a new vdso_linux_amd64.go. This should enable vdso_linux.go to be used for vDSO support on linux architectures other than amd64. - Relocate the elf64X structure definitions appropriate to amd64, and change their names to elfX so that the code in vdso_linux.go is ELFnn-agnostic. - Relocate the sym_keys and corresponding __vdso_* variables appropriate to amd64. - Provide an amd64-specific constant for the maximum byte size of an array, and use this in vdso_linux.go to compute constants for sizing the elf structure arrays traversed in the loaded vDSO. Change-Id: I1edb4e4ec9f2d79b7533aa95fbd09f771fa4edef Reviewed-on: https://go-review.googlesource.com/69391 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Crawshaw authored
Currently we look to see if the main.main symbol address is in the module data text range. This requires access to the main.main symbol, which usually the runtime has, but does not when building a plugin. To avoid a dynamic relocation to main.main (which I haven't worked out how to have the linker generate on darwin), stop using the symbol. Instead record a boolean in the moduledata if the module has the main function. Fixes #22175 Change-Id: If313a118f17ab499d0a760bbc2519771ed654530 Reviewed-on: https://go-review.googlesource.com/69370 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 12 Oct, 2017 17 commits
-
-
David Crawshaw authored
For #22095 Change-Id: I8f48fce571b69a7e8edf2ad7733ffdfd38676e63 Reviewed-on: https://go-review.googlesource.com/70310 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Tobias Klauser authored
Follow CL 41477 and add two more line position tests for yyerror calls in the typechecker which are currently not tested. Update #19683 Change-Id: Iacd865195a3bfba87d8c22655382af267aba47a9 Reviewed-on: https://go-review.googlesource.com/70251Reviewed-by:
Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com>
-
Matthew Dempsky authored
These functions are identical to math/bits.TrailingZeros{32,64}, which are already intrinsified on ppc64. Change-Id: If7ee57e7afe53154874f4b66bacdb6237806128a Reviewed-on: https://go-review.googlesource.com/70350 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Ian Lance Taylor authored
Error was main.go:7:11: error: import error at 162: expected ‘<type ’ Change-Id: Iacfe4bfa003d7708a21ebc89ad1ab2d4a3b041a8 Reviewed-on: https://go-review.googlesource.com/70290 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Than McIntosh <thanm@google.com>
-
Austin Clements authored
When we split separate packages into separate compilation units, we lost PC range information because it was no longer contiguous. This brings it back by constructing proper per-package PC range tables. Change-Id: Id0ab5187e08ac5d13b3d3794977bfc857a56224f Reviewed-on: https://go-review.googlesource.com/69974 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently, the linker generates one huge DWARF compilation unit for the entire Go binary. This commit creates a separate compilation unit and line table per Go package. We temporarily lose compilation unit PC range information, since it's now discontiguous, so harder to emit. We'll bring it back in the next commit. Beyond being "more traditional", this has various technical advantages: * It should speed up line table lookup, since that requires a sequential scan of the line table. With this change, a debugger can first locate the per-package line table and then scan only that line table. * Once we emit compilation unit PC ranges again, this should also speed up various other debugger reverse PC lookups. * It puts us in a good position to move more DWARF generation into the compiler, which could produce at least the CU header, per-function line table fragments, and per-function frame unwinding info that the linker could simply paste together. * It will let us record a per-package compiler command-line flags (#22168). Change-Id: Ibac642890984636b3ef1d4b37fe97f4453c2cc84 Reviewed-on: https://go-review.googlesource.com/69973 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
Heschi Kreinick <heschi@google.com> Reviewed-by:
-
Austin Clements authored
The DWARF code currently clears all section relocations every time it creates a section. This is unnecessary and confusing, so don't do it. This dates back to https://codereview.appspot.com/7891044/diff/26001/src/cmd/ld/dwarf.c. At the time, this was only done for one symbol and that symbol was used solely for collecting relocations (which is why it made sense to clear the relocations but not the actual data). Furthermore, DWARF generation potentially required two passes, so it was important to clear the state from the first pass. None of this is true now, but this pattern had been cargo-culted all over the dwarf.go. Change-Id: I87d4ff8ccd5c807796241559be46168ce3ccb49a Reviewed-on: https://go-review.googlesource.com/70312 Run-TryBot: Austin Clements <austin@google.com> Run-TryBot: Heschi Kreinick <heschi@google.com> Reviewed-by:
-
Austin Clements authored
The .debug_aranges section is an odd vestige of DWARF, since its contents are easy and efficient for a debugger to reconstruct from the attributes of the top-level compilation unit DIEs. Neither GCC nor clang emit it by default these days. GDB and Delve ignore it entirely. LLDB will use it if present, but is happy to construct the index from the compilation unit attributes (and, indeed, a remarkable variety of other ways if those aren't available either). We're about to split up the compilation units by package, which means they'll have discontiguous PC ranges, which is going to make .debug_aranges harder to construct (and larger). Rather than try to maintain this essentially unused code, let's simplify things and remove it. Change-Id: I8e0ccc033b583b5b8908cbb2c879b2f2d5f9a50b Reviewed-on: https://go-review.googlesource.com/69972 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Heschi Kreinick authored
During Mach-O linking, dsymutil takes the DWARF from individual object files and combines it into a debug archive. Because it's content-aware, it doesn't need our help to do its job. Nonetheless, it does try to honor relocations that are present in its input. When dsymutil encounters a relocation, it uses the value of that relocation as an index into the debug map to find its final location. When it does that, it's assuming that the value is an address in the object file. But DWARF references are section-relative. So when it processes a relocation for a DWARF reference, it gets confused, and if the value happens to match the address of a function or data symbol, it will rewrite it incorrectly. Since the relocations don't help, and can hurt, drop them when externally linking a Mach-O binary. Fixes #22068 Change-Id: I8ec36da626575d9f6c8d0e7a0b76eab8ba22d62c Reviewed-on: https://go-review.googlesource.com/68330 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Elias Naur authored
The alternative signal stack doesn't work on ios, so the setup of the alternative stack was skipped. The corresponding unminitSignals was effectively a no-op on ios until CL 70130. Skip unminitSignals on ios to restore the previous behaviour. For the ios builders. Change-Id: I5692ca7f5997e6b9d10cc5f2383a5a37c42b133c Reviewed-on: https://go-review.googlesource.com/70270 Run-TryBot: Elias Naur <elias.naur@gmail.com> Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
The two are not meaningfully different, and it is confusing to have two. Change-Id: Ie6a355ea4d79fb4bb79bf5124071a866038b19ba Reviewed-on: https://go-review.googlesource.com/70211 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Alex Brainman authored
CL 36799 made SetFileCompletionNotificationModes to be called for file handles. I don't think it is correct. Revert that change. Fixes #22024 Fixes #22207 Change-Id: I26260e8a727131cffbf60958d79eca2457495554 Reviewed-on: https://go-review.googlesource.com/69871Reviewed-by:
-
Alex Brainman authored
Current code assumes that SetFileCompletionNotificationModes is safe to call even if we know that it is not safe to use FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag. It appears (see issue #22149), SetFileCompletionNotificationModes crashes when we call it without FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag. Do not call SetFileCompletionNotificationModes in that situation. We are allowed to do that, because SetFileCompletionNotificationModes is just an optimisation. Fixes #22149 Change-Id: I0ad3aff4eabd8c27739417a62c286b1819ae166a Reviewed-on: https://go-review.googlesource.com/69870Reviewed-by:
-
Artyom Pervukhin authored
Decode decodes entire GIF image and returns the first frame as an image.Image. There's no need for it to keep every decoded frame in memory except for the one it returns. Fixes #22199 Change-Id: I76b4bd31608ebc76a1a3df02e85c20eb80df7877 Reviewed-on: https://go-review.googlesource.com/69890Reviewed-by:
-
Austin Clements authored
CL 69292 unified the amd64 entry-points, but Dragonfly doesn't follow the same entry-point argument conventions as most other amd64 platforms. Fix the Dragonfly entry point. Change-Id: I0f84e2e4101ce68217af185ee9baaf455b8b6dad Reviewed-on: https://go-review.googlesource.com/70212 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Ian Lance Taylor authored
Fixes #21054 Change-Id: I016486dc62c04a80727f8da7d1dcec52f2c7f344 Reviewed-on: https://go-review.googlesource.com/62291Reviewed-by:
Giovanni Bajo <rasky@develer.com> Reviewed-by:
Chris Broadfoot <cbro@golang.org>
-
David du Colombier authored
Since CL 46037, the runtime is crashing after calling exitThread on Plan 9. The exitThread function shouldn't be called on Plan 9, because the system manages thread stacks. Fixes #22221. Change-Id: I5d61c9660a87dc27e4cfcb3ca3ddcb4b752f2397 Reviewed-on: https://go-review.googlesource.com/70190 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 11 Oct, 2017 17 commits
-
-
Matthew Dempsky authored
Previously, we were treating cross-package function calls as free for inlining budgeting. In theory, we should be able to recompute InlCost from the exported/reimported function bodies. However, that process mutates the structure of the Node AST enough that it doesn't preserve InlCost. To avoid unexpected issues, just record and restore InlCost in the export data. Fixes #19261. Change-Id: Iac2bc0d32d4f948b64524aca657051f9fc96d92d Reviewed-on: https://go-review.googlesource.com/70151 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Daniel Martí authored
Noticed while reading some code that the two branches in this loop body shared the last statements. Rewrite it in a way that they are not duplicated. Passes toolstash -cmp on std. Change-Id: I3356ca9fa37c32eee496e221d7830bfc581dade1 Reviewed-on: https://go-review.googlesource.com/66470 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Hugues Bruant authored
Calls to a closure held in a local, non-escaping, variable can be inlined, provided the closure body can be inlined and the variable is never written to. The current implementation has the following limitations: - closures with captured variables are not inlined because doing so naively triggers invariant violation in the SSA phase - re-assignment check is currently approximated by checking the Addrtaken property of the variable which should be safe but may miss optimization opportunities if the address is not used for a write before the invocation Updates #15561 Change-Id: I508cad5d28f027bd7e933b1f793c14dcfef8b5a1 Reviewed-on: https://go-review.googlesource.com/65071 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Hugues Bruant <hugues.bruant@gmail.com> Reviewed-by:
Keith Randall <khr@golang.org>
-
Austin Clements authored
Android's libc creates a signal stack for every thread it creates. In Go, minitSignalStack picks up this existing signal stack and puts it in m.gsignal.stack. However, if we later try to exit a thread (because a locked goroutine is exiting), we'll attempt to stackfree this libc-allocated signal stack and panic. Fix this by clearing gsignal.stack when we unminitSignals in such a situation. This should fix the Android build, which is currently broken. Change-Id: Ieea8d72ef063d22741c54c9daddd8bb84926a488 Reviewed-on: https://go-review.googlesource.com/70130Reviewed-by:
-
Joe Tsai authored
In #10909, it was decided that "Deprecated:" is a magic string for tools (e.g., #17056 for godoc) to detect deprecated identifiers. Use those convention instead of custom written prose. Change-Id: Ia514fc3c88fc502e86c6e3de361c435f4cb80b22 Reviewed-on: https://go-review.googlesource.com/70110Reviewed-by:
-
David Chase authored
In order to improve the line numbering for debuggers, it's necessary to trace lines through compilation. This makes it (much) easier to follow. The format of the last column of the ssa.html output was also changed to reduce the spamminess of the file name, which is usually the same and makes it far harder to read instructions and line numbers, and to make it wider and also able to break words when wrapping (long path names still can push off the end otherwise; side-to-side scrolling was tried but was more annoying than the occasional wrapped line). Sample output now, where [...] is elision for sake of making the CL character-counter happy -- and the (##) line numbers are rendered in italics and a smaller font (11 point) under control of a CSS class "line-number". genssa # /Users/drchase/[...]/ssa/testdata/hist.go 00000 (35) TEXT "".main(SB) 00001 (35) FUNCDATA $0, gclocals·7be4bb[...]1e8b(SB) 00002 (35) FUNCDATA $1, gclocals·9ab98a[...]4568(SB) v920 00003 (36) LEAQ ""..autotmp_31-640(SP), DI v858 00004 (36) XORPS X0, X0 v6 00005 (36) LEAQ -48(DI), DI v6 00006 (36) DUFFZERO $277 v576 00007 (36) LEAQ ""..autotmp_31-640(SP), AX v10 00008 (36) TESTB AX, (AX) b1 00009 (36) JMP 10 and from an earlier phase: b18: ← b17 v242 (47) = Copy <mem> v238 v243 (47) = VarKill <mem> {.autotmp_16} v242 v244 (48) = Addr <**bufio.Scanner> {scanner} v2 v245 (48) = Load <*bufio.Scanner> v244 v243 [...] v279 (49) = Store <mem> {int64} v277 v276 v278 v280 (49) = Addr <*error> {.autotmp_18} v2 v281 (49) = Load <error> v280 v279 v282 (49) = Addr <*error> {err} v2 v283 (49) = VarDef <mem> {err} v279 v284 (49) = Store <mem> {error} v282 v281 v283 v285 (47) = VarKill <mem> {.autotmp_18} v284 v286 (47) = VarKill <mem> {.autotmp_17} v285 v287 (50) = Addr <*error> {err} v2 v288 (50) = Load <error> v287 v286 v289 (50) = NeqInter <bool> v288 v51 If v289 → b21 b22 (line 50) Change-Id: I3f46310918f965761f59e6f03ea53067237c28a8 Reviewed-on: https://go-review.googlesource.com/69591 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Ian Lance Taylor authored
This adds the _lib entry point to various GOOS_amd64.s files. A future CL will enable c-archive/c-shared mode for those targets. As far as I can tell, the newosproc0 function in os_darwin.go was passing the wrong arguments to bsdthread_create. The newosproc0 function is never called in the current testsuite. Change-Id: Ie7c1c2e326cec87013e0fea84f751091b0ea7f51 Reviewed-on: https://go-review.googlesource.com/69711 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Lynn Boger authored
Starting in gcc 6, -pie is passed to the linker by default on some platforms, including ppc64le. If the objects being linked are not built for -pie then in some cases the executable could be in error. To avoid that problem, -no-pie should be used with gcc to override the default -pie option and generate a correct executable that can be run without error. Fixes #22126 Change-Id: I4a052bba8b9b3bd6706f5d27ca9a7cebcb504c95 Reviewed-on: https://go-review.googlesource.com/70072 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Crawshaw authored
Along the way, switch to using relocation constants from debug/elf. For #22095 Change-Id: I1a64353619f95dde5aa39060c4b9d001af7dc1e4 Reviewed-on: https://go-review.googlesource.com/69013 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Cherry Zhang authored
It should be skipped on 32-bit architectures. Change-Id: If7a64b9e90e47c3e8734dd62729bfd2944ae926c Reviewed-on: https://go-review.googlesource.com/70071Reviewed-by:
-
Russ Cox authored
Change-Id: Iaa960c85011289e047c64b53cf610838eb50332d Reviewed-on: https://go-review.googlesource.com/70073 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
All of the amd64 entry point code is the same except for Plan 9. Unify it all into asm_amd64.s. Change-Id: Id47ce3a7bb2bb0fd48f326a2d88ed18b17dee456 Reviewed-on: https://go-review.googlesource.com/69292 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Austin Clements authored
There are two places in DWARF generation that create symbols when they really just want to get the symbol if it exists. writeranges, in particular, will create a DWARF range symbol for every single textp symbol (though they won't get linked into any list, so they don't affect the binary). Fix these to use ROLookup instead of Lookup. Change-Id: I401eadf22890e296bd08bccaa6ba2fd8fac800cd Reviewed-on: https://go-review.googlesource.com/69971 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joe Tsai authored
In the distant past, Pipe was implemented with channels and a long running pipe.run goroutine (see CL 994043). This approach of having all communication serialized through the run method was error prone giving Pipe a history of deadlocks and race conditions. After the introduction of sync.Cond, the implementation was rewritten (see CL 4252057) to use condition variables and avoid the long running pipe.run goroutine. While this implementation is superior to the previous one, this implementation is strange in that the p.data field is always set immediately prior to signaling the other goroutine with Cond.Signal, effectively making the combination of the two a channel-like operation. Inferior to a channel, however, this still requires explicit locking around the p.data field. The data+rwait can be effectively be replaced by a "chan []byte" to inform a reader that there is data available. The data+wwait can be effectively be replaced by a "chan int" to inform a writer of how many bytes were read. This implementation is a simplified from net.Pipe in CL 37402. Change-Id: Ia5b26320b0525934fd87a3b69a091c787167f5aa Reviewed-on: https://go-review.googlesource.com/65330 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Bryan Mills <bcmills@google.com>
-
Joe Tsai authored
Implement deadline functionality on Pipe so that it properly implements the semantics of the Conn interface. This aids usages of Pipe (often in unit tests) with a more realistic and complete implementation. The new implementation avoids a dependency on a io.Pipe since it is impossible to keep the prior semantics of synchronous reads and writes while also trying to implement cancelation over an io.{Reader,Writer} that fundamentally has no cancelation support. The fact that net.Pipe is synchronous (and documented as such) is unfortunate because no realistic network connection is synchronous. Instead real networks introduces a read and write buffer of some sort. However, we do not change the semantics for backwards compatibility. The approach taken does not leave any long-running goroutines, meaning that tests that never call Close will not cause a resource leak. Fixes #18170 Change-Id: I5140b1f289a0a49fb2d485f031b5aa0ee99ecc30 Reviewed-on: https://go-review.googlesource.com/37402 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Russ Cox authored
On Windows, not closing f keeps us from being able to remove it. Change-Id: Id4cb709b6ce0b30485b87364a9f0e6e71d2782bd Reviewed-on: https://go-review.googlesource.com/70070 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
It looks like I forgot to reenable this test when I fixed #21522. Update deps.go and reenable. Change-Id: I68a45df09b418f48d93d2e7ab1d274e056c192e6 Reviewed-on: https://go-review.googlesource.com/70050 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
